Last Comment Bug 775301 - Figure out policy for plugins-in-chrome-documents
: Figure out policy for plugins-in-chrome-documents
Status: NEW
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: All All
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Benjamin Smedberg [:bsmedberg]
Depends on: 834918
  Show dependency treegraph
Reported: 2012-07-18 14:23 PDT by Jonas Sicking (:sicking) No longer reading bugmail consistently
Modified: 2013-11-27 10:01 PST (History)
12 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-07-18 14:23:31 PDT
Currently the click-to-play code effectively makes all (or at least many) plugins in chrome documents use click-to-play.

While discussing if this was the correct policy it was brought up if we should allow plugins in chrome documents at all.

This is a bug to figure out which policy to use and implement that policy.
Comment 1 User image Josh Aas 2012-07-18 16:07:20 PDT
I don't think we should allow plugins in chrome at all. Not much to gain, terrible for performance, and adds to future support burdens.
Comment 2 User image Steven Michaud [:smichaud] (Retired) 2012-07-19 07:59:06 PDT
Just to make sure I understand:

Are "chrome documents" documents with "chrome:" URLs?

If so, then allowing plugins in them could also be a security issue, and I'm inclined to agree with Josh.
Comment 3 User image HttpWatch 2012-11-22 06:07:46 PST
We use a plugin in the main browser chrome window for our HttpWatch product (see ). It allows the user interface to be integrated as a docked panel. 

I believe there are other products on the Windows platform that also use plugins to embed a Windows based UI into Firefox. If you removed the ability to host plugins in Chrome then it would make it more difficult for products like ours to work as well in Firefox as it does in Internet Explorer.

We could avoid using a plugin if there was some sort of XUL element that allowed us to embed our own window (HWND based) into our extensions overlay file.
Comment 4 User image Josh Aas 2012-11-26 12:15:43 PST
I'm inclined to say we should deprecate plugins in chrome and perhaps not even allow them to instantiate. It can only really be bad-to-terrible for performance (serious footgun), and I certainly wouldn't want to prioritize any work needed to support it. If people really need to use native code there is always ctypes.
Comment 5 User image Josh Aas 2012-11-26 12:16:54 PST
(In reply to Josh Aas (Mozilla Corporation) from comment #4)

And somehow I didn't realize I already wrote basically the same thing months ago in this same bug! Apologies.
Comment 6 User image Benjamin Smedberg [:bsmedberg] 2012-12-17 07:31:52 PST
I don't have a strong opinion, but it seems that addon authors are currently using plugins for various binary-interop uses and we have recommended that in the past because it is often easier/safer than ctypes. So I think that we probably should keep support for now. And plugins in chrome docs shouldn't be CTP.

Note You need to log in before you can comment on or make changes to this bug.