Re: Should script execution be allowed in designMode documents?

On Thu, Jun 30, 2011 at 4:44 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> That's because you're presupposing what people are using HTML editors for, I
> think.

Undoubtedly.  I haven't seen any real-world web use-cases other than
WYSIWYG editing.

>> (which can't be a huge deal if Chrome hasn't seen issues)
>
> Have they not?  When did they change the behavior from the one seen in
> Safari 5?

I don't know.  They'd have to say.

> For one thing because in the context of a wysiwyg HTML editor (think
> something like an authoring tool, as opposed to a wysiwyg pretty text editor
> that happens to use HTML as its data representation but hides it completely)
> it makes no sense to run the scripts as the author authors them.

I don't get how this would work.  Modifying a script element that's
already in the DOM will not cause anything to execute no matter what.
Adding a script element to the DOM isn't possible using execCommand(),
so authors would have to develop their own function to do it, and
presumably someone going to the effort of writing such an editor could
figure out to avoid script execution by just adding an empty script
element to the DOM and only adding contents to it afterward.

On the other hand, if you set designMode to on for an iframe and then
navigate the iframe so that the user can edit an arbitrary existing
page and maybe save it someplace, probably you don't want the scripts
to run.  After all, if they modify the DOM, you're going to be saving
a different page from the one that was loaded, since you'll have the
DOM changed but you'll also have the original scripts still in the
DOM, and they'll run again when you load the page.  Or maybe the user
wrote the page in the first place including some scripts (added using
non-execCommand() functionality), saved it someplace, loaded it again,
and doesn't want the script to run.  But does anyone actually do this
in practice?

An iframe with designMode has a couple of advantages over
contenteditable for the common WYSIWYG "write a blog post without
knowing HTML" case:

1) It's more robust against browser bugs.  Gecko in particular likes
to throw exceptions for contenteditable in all sorts of common cases
(like <div contenteditable>foo</div>, select "foo" and do
execCommand("indent")).  I've also seen bugs where browsers will
change elements outside of contenteditable ancestors, evidently going
up through the DOM without checking if the element they're looking at
is still editable.  I know my algorithms currently have lots of bugs
like this at the moment.

2) It can more easily be styled separately.

So while I grant that the narrow use-case I outlined above would be
harder to do if script executed when designMode is on, I'm a bit
skeptical about whether it's worth it unless people are actually doing
things like that.  Prohibiting script execution in designMode is
confusing and occasionally inconvenient for relatively little benefit.

If we do prohibit script execution in designMode, though, we should at
least let the script that sets designMode run to execution, if it was
set by the page itself.  IE9 has the fairly crazy behavior that if a
script sets document.designMode = "on", no further statements in the
script execute.  Firefox 6.0a2 and Opera 11.50 seem like they run that
script to completion, but ignore any further scripts.  Chrome 14 dev,
of course, just runs all script.

> In Gecko's case, whole-document designMode is based on code written to
> support the former use case (the old suite's HTML editor, in particular).

That's all very well, but for speccing purposes I'm only concerned
with use-cases on web pages, not use-cases internal to browsers.  The
latter can be done in a nonstandard way.  In my research of real-world
contenteditable/designMode usage so far, which I grant was not
especially thorough or systematic, the only thing I've found is "write
a WYSIWYG blog post" type stuff, and authors use contenteditable and
designMode interchangeably for that purpose.  Unnecessary differences
should be avoided.

Received on Tuesday, 5 July 2011 15:16:33 UTC