User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20100101 Firefox/13.0.1 Build ID: 20120614114901 Steps to reproduce: Reduction here: http://jsfiddle.net/samuelcole/6Te5C/5/ Actual results: No Flash object appears Expected results: The Flash object appears.

Confirmed against Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120627030527 and Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.19) Gecko/2010031422 Firefox/3.0.19 ID:2010031422 (i.e. it never worked). Scrolling gives you a black Rectangle. If you disable Design Mode (doc.designMode = "on"; -> doc.designMode = "off";) there's no Issue.

This happens because we disallow plugins and js in design mode.

Oh, actually I shouldn't have marked it as a dupe. We have discussed why js and plugins are disabled in bug 519928 in length. Short story is that some people want them disabled, others want them enabled. Aryeh, what's your opinion about this?

For the record, you *do* allow plugins in contentEditable=true elements. Just saying...

(In reply to Samuel Cole from comment #5) > For the record, you *do* allow plugins in contentEditable=true elements. > Just saying... Yes, that's true (and ironic!). The current behavior was decided on a long time ago by basically copying what IE did.

I summarized my thoughts on this a year or so ago on public-html in response to a question by Boris: http://lists.w3.org/Archives/Public/public-html/2011Jun/0462.html http://lists.w3.org/Archives/Public/public-html/2011Jul/0069.html Basically, I don't get why script or plugins were ever disabled in designMode. The web use-cases I've seen have been exclusively ones in which the content is written from the start with the intent to be editable -- blog/forum posts, e-mail, etc. No built-in browser features will insert any scripting in this case. If there's anything that runs script, it was added deliberately by whatever code was doing the editing. So why would you not run it? If the editing code didn't want it to be run, they didn't have to add it. If they want to allow the user to insert script that will only run when the page is actually viewed, it's trivial to use classes or data attributes or whatnot, add the actual scripts onsubmit or on display, and remove them before the content is loaded. This is as distinct from the Composer use-case, namely "edit an existing arbitrary webpage". But this use-case is *much* more marginal than writing a blog post or e-mail, and I'm not specifically aware of any web-based tools designed for it. (Composer should be able to turn off scripting directly if it wants using privileged APIs, it doesn't need to rely on web features like designMode.) Moreover, as Ojan has pointed out, you can use sandboxed iframes to emulate the effect if you want it. Not all browsers support them, but not all browsers support not running script in designMode, either. And once *we* support sandboxed iframes, we can always tell authors to just sandbox the iframe -- then they'll work in old Firefox because it didn't run script in designMode at all, and also new Firefox because of the sandbox. I've skimmed bug 519928 and I don't see anything to change my mind. WebKit proves this shouldn't break too many sites. If authors want to be able to disable script in editable iframes, we could block on bug 341604 (iframe sandbox).

In the past people have been worrying about pasted content running plugins and scripts (which I _think_ why IE blocks these) but we've since fixed that by sanitizing the pasted content. It makes sense for us to wait for bug 341604 here.

(In reply to Ehsan Akhgari [:ehsan] from comment #8) > In the past people have been worrying about pasted content running plugins > and scripts (which I _think_ why IE blocks these) but we've since fixed that > by sanitizing the pasted content. > > It makes sense for us to wait for bug 341604 here. just a note that the HTML 5 spec for iframe sandbox specifies plugins must always be disabled in an sandboxed iframe (unless the plugin is 'securable', see the spec for more details, but AFAIK the most popular plugins don't qualify currently) - there is no 'allow-plugins' keyword, as there is an 'allow-scripts' to opt back into executing scripts.

That's only a problem if someone wants 1) a page to be editable, 2) but with no scripts running, 3) but *with* plugins. Is that realistic? Especially given that plugins are rapidly declining in popularity?

That's a very hard question to answer without making possibly flaky assumptions...

Personally, my use case is that we allow people to embed youtube videos, etc. into our editor. It's nice to allow them to watch the videos (and just see the embeds) directly in the editor. I have since switched to contentEditable (I wanted those embeds not to be editable anyways, so contentEditable is the correct fit for that case).

This came up in bug 827035, and bz filed a bug for spec clarification: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20579

I don't know whether plug-ins are actually getting enabled, fwiw. But script is. ;)

https://hg.mozilla.org/integration/mozilla-inbound/rev/fc80e729a417 https://hg.mozilla.org/integration/mozilla-inbound/rev/fbc229932c90

https://hg.mozilla.org/mozilla-central/rev/fc80e729a417 https://hg.mozilla.org/mozilla-central/rev/fbc229932c90