Closed Bug 1237402 Opened 4 years ago Closed 4 years ago

Allow certain plugins to be loaded in parent process

Categories

(Core :: Plug-ins, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla47
Tracking Status
e10s + ---
firefox46 - unaffected
firefox47 + fixed

People

(Reporter: billm, Assigned: billm)

References

Details

Attachments

(1 file)

Attached patch patchSplinter Review
There seem to be a good number of add-ons that bundle an NPAPI plugin and load the plugin through a chrome: URL. IE Tab is one example. Right now we don't allow this in e10s because plugins can only be loaded in the child process. That was to eliminate hangs (bug 1155976).

However, talking this over with Brad, I realized that these plugins aren't going to cause hangs because they're never going to be loaded in a child process. The hang problem only occurs if the same plugin is loaded in both the parent and the child.

So this patch allows certain plugins to be whitelisted so that they run in the parent, based on a pref. Add-ons will be able to change these prefs to make their plugins run in the parent. We'll also be able to change them with a hotfix.
Attachment #8704792 - Flags: review?(jmathies)
Benjamin was removing code to support this a few months ago. I'm not sure if anything landed that would get in the way here. ni'ing him so he's aware of this bug.
Flags: needinfo?(benjamin)
You might be thinking of removing code for in-process plugins, which is different. In this case, the plugin still runs OOP, but the <object> element is in the parent process.
I'm fine with a flag/pref that will allow a plugin to run only in chrome instead of only in content.

I still don't think we want to allow plugins to run in-process. I'm not sure whether the IETab plugin runs in OOPP mode correctly or not.
Flags: needinfo?(benjamin)
IETab seems to run OOP, but it has an option to run in-process. They a some weird message about how it's needed if you have another add-on. Anyway, it's not relevant to this bug.
Attachment #8704792 - Flags: review?(jmathies) → review+
Duplicate of this bug: 1241023
https://hg.mozilla.org/mozilla-central/rev/3700036fec88
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
Tracking for 46 since this is related to a feature we are aiming to ship in 46. 
Do you want to uplift this to aurora?
Flags: needinfo?(wmccloskey)
tracking-e10s: --- → ?
Duplicate of this bug: 1230870
Users with add-ons will not get e10s in 46. So this shouldn't track 46.
Flags: needinfo?(wmccloskey)
(In reply to Bill McCloskey (:billm) from comment #10)
> Users with add-ons will not get e10s in 46. So this shouldn't track 46.

Oh? Well I thought I had noticed that all my tabs were (e10s) on 46.0a1 (and now on 47.0a1 too); and yet I have several XPI extensions, one (admittedly currently disabled) complete theme in addition to Defaut and Dev Edition, and a number of 64-bit NPAPI plugins to boot. Will this e10s default become disabled when 46.0 upgrades to aurora to beta to release?
Assuming tony wants to keep using 46 and will follow it with the same profile from aurora to beta to release, is this what will happen?  If he has some themes and addons installed, but disabled, then moves his profile to 46 beta, will he have e10s turned on by default or not?  I'm not sure.
Flags: needinfo?(wmccloskey)
Untracking from Bill's suggestion in comment 10.
If a user with add-ons switches channels to follow the 46 train, then they will find that e10s is disabled when 46 goes to release, and possibly in beta as well (depending on whether they get selected for the e10s experiment that we'll likely run for the 46 beta). The e10s switching code won't be confused by the fact that you had e10s on a different channel.
Flags: needinfo?(wmccloskey)
based on this fix - are things like IE Tab v2 Bug 1068060 considered e10s compatible?  I got a bit confused if the flag was just to help them run on aurora & beta, but turned off in Release.
Flags: needinfo?(wmccloskey)
These addons would need to set a pref for their specific plugin to force it into chrome mode. Then it would probably be compatible.

But you should also be aware that we're dropping support for NPAPI plugins in Firefox 52, and so these addons will break soon anyway.
Flags: needinfo?(wmccloskey)
You need to log in before you can comment on or make changes to this bug.