1237402 - Allow certain plugins to be loaded in parent process

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: patch

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.

Comment 1

[Jim Mathies [:jimm]]

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.

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 3

[Benjamin Smedberg]

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.

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 5

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3700036fec88

Comment 7

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/3700036fec88

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

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?

Comment 10

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Users with add-ons will not get e10s in 46. So this shouldn't track 46.

Comment 11

[Tony Mechelynck [:tonymec]]

(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?

Comment 12

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

Untracking from Bill's suggestion in comment 10.

Comment 14

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 15

[:shell escalante]

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.

Comment 16

[Benjamin Smedberg]

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.