bug: incremental="true" ignored on textarea with mediatype="text/html"

If you set incremental="true" on a textarea with text/html mediatype (using YUI RTE) then the resulting field is not incremental.

html-area-incremental.xhtml

Ok I read at http://wiki.orbeon.com/forms/doc/developer-guide/xforms-controls#TOC-Limitations and in the code that this is a new limitation, as a result of the server-side HTML cleanup.

This is a real pity, since previously it worked ok.

On balance I think I'd prefer incremental support over cleaned up HTML !

Adrian Baker wrote

If you set incremental="true" on a textarea with text/html mediatype (using YUI RTE) then the resulting field is not incremental.

html-area-incremental.xhtml

Hi Adrian,

Adrian Baker wrote

Ok I read at http://wiki.orbeon.com/forms/doc/developer-guide/xforms-controls#TOC-Limitations and in the code that this is a new limitation, as a result of the server-side HTML cleanup.

This is a real pity, since previously it worked ok.

On balance I think I'd prefer incremental support over cleaned up HTML !

I understand that in some cases you'd prefer that. But note that it is not just a matter of the HTML being "clean", it is a matter of security: if the HTML isn't sanitized, and is then displayed to other users (which applications often do), this opens the door to XSS attacks (http://en.wikipedia.org/wiki/Cross-site_scripting).

Maybe there is a way to have both the clean-up and the incremental mode working at the same time? Do you have ideas on how to do that?

Alex

Perhaps you could clean only on submit, since without a submission there isn't any way to propagate the insecure HTML to another user.

That's sort of sidestepping the issue though, and it would still break if you had a background submission while editing the RTE (eg a periodic autosave, which we do).

I think having two different components reformatting the same HTML is problematic - right now in IE we're having an issue where as soon as you focus on any input on a newly load page (not even the RTE), the RTE fires a xforms-value-changed, I think perhaps as YUI reformats the initially server-side formatted HTML. I will have to come up with a an example for the sandbox. Semantically the HTML might be identical ( versus , but the changes still result (quite correctly) in change events.

Perhaps it would be easier to simply reject certain HTML deemed insecure, rather than cleaning it up, on the assumption that no-one wants to use the YUI RTE to enter script into? That way you only have one HTML serializer (YUI).

Adrian

Alessandro Vernet wrote

Hi Adrian,

Adrian Baker wrote

Ok I read at http://wiki.orbeon.com/forms/doc/developer-guide/xforms-controls#TOC-Limitations and in the code that this is a new limitation, as a result of the server-side HTML cleanup.

This is a real pity, since previously it worked ok.

On balance I think I'd prefer incremental support over cleaned up HTML !

I understand that in some cases you'd prefer that. But note that it is not just a matter of the HTML being "clean", it is a matter of security: if the HTML isn't sanitized, and is then displayed to other users (which applications often do), this opens the door to XSS attacks (http://en.wikipedia.org/wiki/Cross-site_scripting).

Maybe there is a way to have both the clean-up and the incremental mode working at the same time? Do you have ideas on how to do that?

Alex

"( versus "  -->  "(<font/> versus <font><font/>)"

Adrian Baker wrote

Semantically the HTML might be identical ( versus , but the changes still result (quite correctly) in change events.

> Perhaps you could clean only on submit, since without a submission  
> there
> isn't any way to propagate the insecure HTML to another user.
>
> That's sort of sidestepping the issue though, and it would still  
> break if
> you had a background submission while editing the RTE (eg a periodic
> autosave, which we do).

As you say ;)
Interesting idea. I could imagine the client just ignoring the value  
(and logging the event).

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

Adrian,

Adrian Baker wrote

Perhaps it would be easier to simply reject certain HTML deemed insecure, rather than cleaning it up, on the assumption that no-one wants to use the YUI RTE to enter script into? That way you only have one HTML serializer (YUI).

I am just thinking out loud here, but maybe another way to deal with this is to never replace the value in the RTE with the value from the server if the RTE has the focus. This way the editor could still be incremental, you can still update its value dynamically (say if the user clicks on a trigger) but you just can't update it as the user types in the field. Would that be a workable compromise?

Alex

Alessandro Vernet wrote

I am just thinking out loud here, but maybe another way to deal with this is to never replace the value in the RTE with the value from the server if the RTE has the focus. This way the editor could still be incremental, you can still update its value dynamically (say if the user clicks on a trigger) but you just can't update it as the user types in the field. Would that be a workable compromise?

Alex

I think it would be yes. It wouldn't be a true incremental in some corner cases (eg say you have a calculate expression on the value), but in general it would work well.

Adrian,

Exactly. Do you feel like updating xforms.js to do this? ;)

Alex

Adrian Baker wrote

Alessandro Vernet wrote

I am just thinking out loud here, but maybe another way to deal with this is to never replace the value in the RTE with the value from the server if the RTE has the focus. This way the editor could still be incremental, you can still update its value dynamically (say if the user clicks on a trigger) but you just can't update it as the user types in the field. Would that be a workable compromise?

Alex

I think it would be yes. It wouldn't be a true incremental in some corner cases (eg say you have a calculate expression on the value), but in general it would work well.

It looks like a straightforward change. Wrapping setValue in a check for focus:

        /**
         * Called to set the value of the RTE
         */
        setValue: function(control, newValue) {
        // Don't update the textarea with HTML from the server while the user is typing, otherwise the user
        // loses their cursor position. This lets us have a certain level of support for incremental rich text areas,
        // however, ignoring server values means that the visual state of the RTE can become out of sync
        // with the server value (for example, the result of a calculation wouldn't be visible until focus moved
        // out of the field).
        if(ORBEON.util.Dom.hasClass(control, "xforms-incremental") && ORBEON.xforms.Globals.currentFocusControlId != control.id) {
                    var yuiRTE = rteEditors[control.id];
                    yuiRTE.setEditorHTML(newValue);
        }
        },

Then removing the test for xforms-mediatype-text-html && xforms-textarea in the incremental check in ORBEON.xforms.Events.keyup.

Rather hacky but seems to work well.

Adrian

Alessandro Vernet wrote

Adrian,

Exactly. Do you feel like updating xforms.js to do this? ;)

Alex

Adrian Baker wrote

Alessandro Vernet wrote

I am just thinking out loud here, but maybe another way to deal with this is to never replace the value in the RTE with the value from the server if the RTE has the focus. This way the editor could still be incremental, you can still update its value dynamically (say if the user clicks on a trigger) but you just can't update it as the user types in the field. Would that be a workable compromise?

Alex

I think it would be yes. It wouldn't be a true incremental in some corner cases (eg say you have a calculate expression on the value), but in general it would work well.

Adrian,

Excellent; thank you! I checked in this change. You'll find it in the next nightly build. For reference the RFE is:

http://forge.ow2.org/tracker/index.php?func=detail&aid=313935&group_id=168&atid=350207

Alex

Adrian Baker wrote

It looks like a straightforward change. Wrapping setValue in a check for focus:

        /**
         * Called to set the value of the RTE
         */
        setValue: function(control, newValue) {
        // Don't update the textarea with HTML from the server while the user is typing, otherwise the user
        // loses their cursor position. This lets us have a certain level of support for incremental rich text areas,
        // however, ignoring server values means that the visual state of the RTE can become out of sync
        // with the server value (for example, the result of a calculation wouldn't be visible until focus moved
        // out of the field).
        if(ORBEON.util.Dom.hasClass(control, "xforms-incremental") && ORBEON.xforms.Globals.currentFocusControlId != control.id) {
                    var yuiRTE = rteEditors[control.id];
                    yuiRTE.setEditorHTML(newValue);
        }
        },

Then removing the test for xforms-mediatype-text-html && xforms-textarea in the incremental check in ORBEON.xforms.Events.keyup.

Rather hacky but seems to work well.

Adrian

Alessandro Vernet wrote

Adrian,

Exactly. Do you feel like updating xforms.js to do this? ;)

Alex

Adrian Baker wrote

Alessandro Vernet wrote

I am just thinking out loud here, but maybe another way to deal with this is to never replace the value in the RTE with the value from the server if the RTE has the focus. This way the editor could still be incremental, you can still update its value dynamically (say if the user clicks on a trigger) but you just can't update it as the user types in the field. Would that be a workable compromise?

Alex

I think it would be yes. It wouldn't be a true incremental in some corner cases (eg say you have a calculate expression on the value), but in general it would work well.