- From: Ojan Vafai <ojan@chromium.org>
- Date: Tue, 18 May 2010 10:35:44 -0700
On Fri, Apr 23, 2010 at 2:34 AM, Robert O'Callahan <robert at ocallahan.org>wrote: > On Fri, Apr 23, 2010 at 6:52 PM, Simon Pieters <simonp at opera.com> wrote: > >> It seems Hixie has decided to go back to the WebKit behavior in the spec >> for designMode. >> >> http://html5.org/tools/web-apps-tracker?from=2817&to=2818 >> > > It's certainly the easiest to implement, but you can see feedback in > https://bugzilla.mozilla.org/show_bug.cgi?id=519928 that this makes life > difficult for people writing editors. > > Thanks for the links. > The webkit behavior of allowing all scripts makes the most sense to me. It should be possible to disable scripts, but that capability shouldn't be tied to editability. The clean solution for the CKEditor developer is to use a sandboxed iframe. I don't see a security benefit for disabling script as you'd have all the same issues with loading any user-content in a non-editable area. The only catch is that you *do* need to disable script from pasted and drag-dropped content (see http://trac.webkit.org/changeset/53442). Basically, any site serving user-content will already need to mitigate XSS some other way, so disabling script in editable areas is not necessary, but paste/drag-drop can't reasonably rely on server-side solutions, so must be done by the UA. Putting my developer hat on, trying to make Google Gadgets work in Google's rich text editor inside Firefox designMode was awful due to https://bugzilla.mozilla.org/show_bug.cgi?id=519928. A large percentage of Google Gadgets load as iframes and require javascript onload. We had to play tricks with turning off designMode, appending the iframe and turning designMode back on. It was an awful solution that never worked very well. Ojan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100518/0bf4f109/attachment.htm>
Received on Tuesday, 18 May 2010 10:35:44 UTC