On Jan 29, 2010, at 3:33 PM, Jerome Velociter wrote:

Vincent Massol wrote:

...

On Jan 29, 2010, at 3:04 PM, Marius Dumitru Florea wrote:

...

Hi devs,

Right now JavaScript extensions are included when a document is rendered in WYSIWYG edit mode. This has both advantages and disadvantages.

Pro: If the output of a macro depends on a JavaScript extension, then the result of rendering that macro will be the same in view mode and (WYSIWYG) edit mode.

Con: If the JavaScript extension is not aware of the edit mode then it can modify the DOM document outside of the read-only macro markers which leads to unwanted changes in the content of the edited document (i.e. the modifications done by the JavaScript extension are saved). Such an example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .

Before deciding isn't there a possibility to protect the DOM? Is there no way to do that?

What do you mean protect the DOM ?

If you mean prevent DOM modifications by the extensions, I think it is a hard problem, and it does not really make sense (what the point of including extensions to not discriminate vs. view mode if in the end they cannot affect the DOM ?)

But maybe that's not what you mean.

No I meant protect the DOM when in wysiwyg edit mode. I have no idea if it's possible. We have the same issue for the XDOM when a transformation makes a change in other parts of the XDOM and we need to protect it (by adding markers around the changes). The way I plan to implement this is to implement a TransformationXDOM which is an extension of the default XOM implementation and that automatically adds markers when a change is done outside of its zone. Thanks -Vincent

Jerome.

...

We're going to do something a little similar for the rendering is there's invalid HTML entered: http://jira.xwiki.org/jira/browse/XWIKI-3782

Thanks -Vincent

...

WDYT? Should we limit the WYSIWYG in order to make the editing safer?

I'm +0.

Thanks, Marius

Vincent Massol wrote:

On Jan 29, 2010, at 3:33 PM, Jerome Velociter wrote:

...

Vincent Massol wrote:

...

On Jan 29, 2010, at 3:04 PM, Marius Dumitru Florea wrote:

...

Hi devs,

Right now JavaScript extensions are included when a document is rendered in WYSIWYG edit mode. This has both advantages and disadvantages.

Pro: If the output of a macro depends on a JavaScript extension, then the result of rendering that macro will be the same in view mode and (WYSIWYG) edit mode.

Con: If the JavaScript extension is not aware of the edit mode then it can modify the DOM document outside of the read-only macro markers which leads to unwanted changes in the content of the edited document (i.e. the modifications done by the JavaScript extension are saved). Such an example is http://jira.xwiki.org/jira/browse/XWIKI-4665 . Before deciding isn't there a possibility to protect the DOM? Is there no way to do that? What do you mean protect the DOM ?

If you mean prevent DOM modifications by the extensions, I think it is a hard problem, and it does not really make sense (what the point of including extensions to not discriminate vs. view mode if in the end they cannot affect the DOM ?)

But maybe that's not what you mean.

No I meant protect the DOM when in wysiwyg edit mode.

I have no idea if it's possible. We have the same issue for the XDOM when a transformation makes a change in other parts of the XDOM and we need to protect it (by adding markers around the changes). The way I plan to implement this is to implement a TransformationXDOM which is an extension of the default XOM implementation and that automatically adds markers when a change is done outside of its zone.

I don't think this is possible. DOM changes can come from different places: the editor, in-line JavaScript, JavaScript extensions (including third-party JavaScript libraries). Catching DOM mutations is not possible in IE, and how can we detect the entity behind the DOM mutation (especially when it's a third-party JavaScript library)? Moreover, I'm not sure it's possible to wrap all the JavaScript DOM API to be able to detect for instance when a DOM node is added to the document. Note that a macro would still be able to generate in-line JavaScript (though the best practice is to have this code in a JavaScript extension). Thanks, Marius

Thanks -Vincent

...

Jerome.

...

We're going to do something a little similar for the rendering is there's invalid HTML entered: http://jira.xwiki.org/jira/browse/XWIKI-3782

Thanks -Vincent

...

WDYT? Should we limit the WYSIWYG in order to make the editing safer?

I'm +0.

Thanks, Marius

---

devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Marta Girdea wrote:

On Fri, Jan 29, 2010 at 3:04 PM, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:

...

Hi devs,

Right now JavaScript extensions are included when a document is rendered in WYSIWYG edit mode. This has both advantages and disadvantages.

Pro: If the output of a macro depends on a JavaScript extension, then the result of rendering that macro will be the same in view mode and (WYSIWYG) edit mode.

Con: If the JavaScript extension is not aware of the edit mode then it can modify the DOM document outside of the read-only macro markers which leads to unwanted changes in the content of the edited document (i.e. the modifications done by the JavaScript extension are saved). Such an example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .

Would XSKINX-14 (Let extensions declare a list of web actions (view, edit, etc.) it should be pulled for) fix at least some of the issues?

Not necessarily. Take for instance XWIKI-4665. I think the user should be able to jump to a page even when in edit mode as long as the focus is not on the rich text area. When the focus is on the rich text area the shortcut key is triggered for the inner (edited) document and the jump to page feature should be disabled. XSKINX-14 could be a solution if the inner (edited) document were loaded with a different action (right now the action is edit). Thanks, Marius

...

WDYT? Should we limit the WYSIWYG in order to make the editing safer?

...

I'm +0.

Thanks, Marius _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Marius Dumitru Florea wrote:

Marius Dumitru Florea wrote:

...

Hi devs,

Right now JavaScript extensions are included when a document is rendered in WYSIWYG edit mode. This has both advantages and disadvantages.

Pro: If the output of a macro depends on a JavaScript extension, then the result of rendering that macro will be the same in view mode and (WYSIWYG) edit mode.

Con: If the JavaScript extension is not aware of the edit mode then it can modify the DOM document outside of the read-only macro markers which leads to unwanted changes in the content of the edited document (i.e. the modifications done by the JavaScript extension are saved). Such an example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .

WDYT? Should we limit the WYSIWYG in order to make the editing safer?

FYI, I get a JavaScript exception ("XWiki is not defined") if I edit Main.AllDocs when javascript.vm template is not imported in WYSIWYG editing mode. Should the live table macro check if the XWiki JavaScript object is present?

Yes It should. Thanks for catching this. Jerome.

Thanks, Marius

...

I'm +0.

Thanks, Marius _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Sergiu Dumitriu wrote:

On 01/29/2010 03:48 PM, Jerome Velociter wrote:

...

Marius Dumitru Florea wrote:

...

FYI, I get a JavaScript exception ("XWiki is not defined") if I edit Main.AllDocs when javascript.vm template is not imported in WYSIWYG editing mode. Should the live table macro check if the XWiki JavaScript object is present? Yes It should. Thanks for catching this.

Errr, no?

Correct, I spoke too fast. I thought the livetable did not check for the XWiki namespace presence but it does. (Indeed it would not work if not)

If the XWiki object is not defined, then how will it work? I think the XWiki object is defined in the parent frame, so this would be better:

if (typeof(XWiki) == 'undefined') { if (typeof(window.parent.XWiki) != 'undefined') { XWiki = window.parent.XWiki; } else { // Critical, what now? } }

On 01/29/2010 04:08 PM, Sergiu Dumitriu wrote:

On 01/29/2010 03:04 PM, Marius Dumitru Florea wrote:

...

Hi devs,

Right now JavaScript extensions are included when a document is rendered in WYSIWYG edit mode. This has both advantages and disadvantages.

Pro: If the output of a macro depends on a JavaScript extension, then the result of rendering that macro will be the same in view mode and (WYSIWYG) edit mode.

Con: If the JavaScript extension is not aware of the edit mode then it can modify the DOM document outside of the read-only macro markers which leads to unwanted changes in the content of the edited document (i.e. the modifications done by the JavaScript extension are saved). Such an example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .

WDYT? Should we limit the WYSIWYG in order to make the editing safer?

I'm +0.

+1

If some script should be executed in edit mode, I think a possible solution would be to add a new field to the JSX class to tell if the extension should be used in edit mode, too. By default it should be false. The problem is that this doesn't fix file extensions, and those are the ones that cause problems now. So, at least for file extensions, they should always be disabled in edit mode.

Actually we can use a parameter for file extensions too, in the extra params parameter. -- Sergiu Dumitriu http://purl.org/net/sergiu/