Closed Bug 788399 Opened 7 years ago Closed 4 years ago

Remove in-process windowless plugin support for WINNT and X11

Categories

(Core :: Plug-ins, defect)

18 Branch
defect
Not set

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: karlt, Assigned: karlt)

References

Details

(Whiteboard: [leave open])

Attachments

(4 files, 2 obsolete files)

In-process windowless plugins are a security risk and not enabled by default
on WINNT and X11 at least.  On those platforms we should return false for
NPNVSupportsWindowless to in-process plugins and remove related support code.

Oracle's Java plugin doesn't have windowless support.

Firefox still runs some plugins in-process on x86-Mac and Android.
Android plugins are windowless.
Mac plugins do not have nsNPAPIPluginInstance::mWindowless set but they do have similarities to windowless plugins (and windowed plugins).
I don't know which drawing models we need to continue to support for x86-Mac
in-process plugins.
Blocks: 733322
The first step of disabling windowless plugins should land first, leaving the support code around in case there are unforeseen problems.  The code can be removed in a separate bug.
QA Contact: karlt
Assignee: nobody → karlt
QA Contact: karlt
Some initial cleanup to make things easier to follow.

_getValue in PluginModuleChild doesn't use NPN_GetValue for these variables
since bug 526401 landed.
Still need to look at how many of the dom/plugins/test/mochitest tests to still run with --setpref=dom.ipc.plugins.enabled=false
(In reply to Karl Tomlinson (:karlt) from comment #3)
> Still need to look at how many of the dom/plugins/test/mochitest tests to
> still run with --setpref=dom.ipc.plugins.enabled=false

mochitest-ipcplugins, which runs as part of the "mochitest-other" group, runs all the plugin mochitests with that pref (I'm not sure if that's exactly what you were asking.)
Added changes to dom/plugins/test/mochitest tests, now that these plugins are windowed when dom.ipc.plugins.enabled=false.

dom/plugins/test/mochitest is only used for gtk2, cocoa, and windows.
bug539565 and bug751809 tests use synthesized mouse clicks.
test_visibility is intended only for windowless plugins and not run on mac.
To benefit from above changes, OOP windowless plugins need to be using async
drawing.

The only situation where we have OOP plugins but sync drawing seems to be b2g,
where plugin.disable is set.  Requesting feedback from cjones just to confirm
no plans to add sync OOP plugin drawing there.
Attachment #658805 - Attachment is obsolete: true
Attachment #659993 - Flags: feedback?(jones.chris.g)
The changes were effective for the X11 Flash Player, but on WinXP, Flash Player
and Silverlight seem to ignore the return code from _setvalue
NPPVpluginWindowBool and not check NPNVSupportsWindowless.
Flash Player fails to draw to the window when windowless mode is not available.  Similar trouble with Silverlight in attachment 304628 [details].

We should be able to force plugins into windowed mode by removing their
wmode/windowless attributes or parameters.

Successful opt try run with changes to date:
https://tbpl.mozilla.org/?tree=Try&pusher=ktomlinson@mozilla.com
Comment on attachment 659993 [details] [diff] [review]
always use async drawing for OOP windowless plugins

Plugins will never be supported by b2g.
Attachment #659993 - Flags: feedback?(jones.chris.g) → feedback+
(In reply to Karl Tomlinson (:karlt) from comment #7)
> We should be able to force plugins into windowed mode by removing their
> wmode/windowless attributes or parameters.
What about removing the in-process mode support? We already dropped the support on >=Vista.
I wondered about that, but bug 785047 might be a reason to keep/restore that option in some situations.
Java needs to remain in-process on Windows because of their modal dialogs.
Attachment #658803 - Flags: review?(benjamin)
We should be able to force WINNT plugins into windowed mode by removing their
wmode/windowless attributes or parameters, but that is not trivial with the way we currently handle parameters.

Disabling X11 in-process windowless plugins does not need to wait on that, so let's get this started.
Attachment #664672 - Flags: review?(benjamin)
Attachment #659993 - Flags: review?(benjamin)
This part still needs removal of wmode/windowless parameters.
Attachment #659991 - Attachment is obsolete: true
I wonder if this has any real chance of success. I think that to the extent we need to keep supporting in-process plugins, we should just fix the sync-drawing issue by asynchronously double-buffering the in-process plugins the same way we do OOPP. This is going to be a QA nightmare because a noticeable number of users (especially on WinXP) still force OOPP off. And we're asking Adobe to support only windowless mode in new versions of FP.
Attachment #659993 - Flags: review?(benjamin) → review+
Attachment #658803 - Flags: review?(benjamin) → review+
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #15)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #15)
> I wonder if this has any real chance of success. I think that to the extent
> we need to keep supporting in-process plugins, we should just fix the
> sync-drawing issue by asynchronously double-buffering the in-process plugins
> the same way we do OOPP. This is going to be a QA nightmare because a
> noticeable number of users (especially on WinXP) still force OOPP off. And
> we're asking Adobe to support only windowless mode in new versions of FP.

It would be possible to do async drawing in-process, perhaps with some extra
issues of balancing plugin drawing frequency against our response times.
However, I'm not keen on developing the in-process support that we are trying
to deprecate.

The only plugins that we run in process by default (on non-Mac platforms) are
those supporting java MIME types.  Java plugins don't support windowless mode.

If Adobe were to drop windowed support before we force Flash OOP on WinXP (or
other WINNT systems if we re-enable there), then that would be a problem.
So that may be a reason not to pursue this on WINNT.

On X11, I don't think we have that problem because Adobe is no longer
developing their X11 plugin.

An alternative approach might be to force OOP plugins that we know support
windowless mode.  However, it would still make sense to indicate that we don't
support X11 in-process windowless for new plugins or new versions of plugins. 

Somehow, removing the X11 windowless in-process support in-general feels better than picking particular plugins to force OOP.
These patches are sensible regardless of the future direction here, so landed them.
https://hg.mozilla.org/integration/mozilla-inbound/rev/02e1a6c14726
https://hg.mozilla.org/integration/mozilla-inbound/rev/b8fa6f780f38
Whiteboard: [leave open]
Attachment #658803 - Flags: checkin+
Attachment #659993 - Flags: checkin+
We've removed support for in-process plugins entirely, so this is now somewhere between FIXED and WONTFIX. So of course I'm going to choose INCOMPLETE.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
Attachment #664672 - Flags: review?(benjamin)
You need to log in before you can comment on or make changes to this bug.