1194780 - Remove support for in-process plugins

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Benjamin Smedberg]

Currently we have support to run plugins in-process or out-. In-process plugins are now a pretty bad idea and we've stopped supporting that, so I'm going to try and remove a bunch of the code related to it.

I'm considering consolidating dom/plugins/base and dom/plugins/ipc as well. Josh do you have opinions about that?

Comment 2

[leichixian]

I don't support your idea. In some situations, there are some sites written for old versions of Internet Explorer and we can't make the site owner to change its code. However, we have to use it everyday (For example many government and school sites in China). In-process plugin give a solution to load such pages via a plugin which calls IE and can deal with these sites properly. If you remove the support to this tweak, such tasks can only be done with IE and users will say "How bad Firefox is! It even can't help me select courses!" and our users will use other browsers which support such tweak. This is what we don't want to see. I know in western countries this seldom happens, but in China such thing always happen. So I suggest at least support this for zh-CN locale.

Comment 3

[leichixian]

@patwonder What is your opinion?

Comment 4

[Fusion Future]

If it is removed, will FireIE addon still work properly? Is there a solution?

Comment 5

[patwonder]

(In reply to leichixian from comment #2)
> I don't support your idea. In some situations, there are some sites written
> for old versions of Internet Explorer and we can't make the site owner to
> change its code. However, we have to use it everyday (For example many
> government and school sites in China). In-process plugin give a solution to
> load such pages via a plugin which calls IE and can deal with these sites
> properly. If you remove the support to this tweak, such tasks can only be
> done with IE and users will say "How bad Firefox is! It even can't help me
> select courses!" and our users will use other browsers which support such
> tweak. This is what we don't want to see. I know in western countries this
> seldom happens, but in China such thing always happen. So I suggest at least
> support this for zh-CN locale.

(In reply to Fushan Wen from comment #4)
> If it is removed, will FireIE addon still work properly? Is there a solution?

Fire IE supports out-of-process plugin mode, thus in-process plugin support is not the major obstacle that prevents Fire IE from working in the latest versions of Firefox. The major obstacles are:

1. Removal of ability to load plugins by pages loaded in the chrome(UI) process when e10s is enabled (Bug 1155976). Fire IE thus can only work in non-e10s mode.

2. Firefox x64 does not support plugins other than Shockwave Flash (Bug 1165981). Thus Fire IE can only work in 32-bit Firefox when Firefox 41 is released.

If anyone wants to use Fire IE with e10s enabled or with x64 Firefox, I would suggest using a 3rd-party build, e.g. pcxfirefox.

Comment 6

[James Willcox (:snorp) ([e-mail]) (he/him)]

This apparently landed with the wrong bug number, bug 1098064.

(https://bugzilla.mozilla.org/show_bug.cgi?id=1098064#c5

https://hg.mozilla.org/integration/mozilla-inbound/rev/e4c9fd404528
https://hg.mozilla.org/integration/mozilla-inbound/rev/4e8302a104fb

Comment 7

[Guilherme Lima]

This landed on MC on Thursday morning:
https://hg.mozilla.org/mozilla-central/rev/32e5b68506f4
https://hg.mozilla.org/mozilla-central/rev/e4c9fd404528
https://hg.mozilla.org/mozilla-central/rev/4e8302a104fb

Comment 8

[Guilherme Lima]

Actually, it seems they were about bug 874167, right? Very sorry for the noise.

Comment 9

[Josh Aas]

I see I am very late to giving input here, but I'll give it anyway. I think it's fine to remove non-OOP support. Fewer code paths and reduced complexity is a good thing, and there are very few good reasons to be running NPAPI plugins in-process.

The only thing I liked it for was debugging, it was often easier to debug basic problems in-process, but not worth keeping those code paths for this minor convenience.

Comment 10

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

Benjamin, should this have a release note?

Comment 11

[Benjamin Smedberg]

It might be useful. Here's a draft:

CHANGE: In preparation for multi-process content in future releases, single-process mode is no longer supported for NPAPI plugins. The preferences under dom.ipc.plugins are no longer used.

Comment 12

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

Adding "dev-doc-needed" as it would be good to have something to link to from the release notes.

Comment 13

[Eric Shepherd [:sheppy]]

Do we have any specifics on what makes a plugin capable of being used in multi-process mode? I want to be sure that I cover this adequately, at least in terms of just saying what will and will not let a plugin work.

Comment 14

[Eric Shepherd [:sheppy]]

A note has been added to https://developer.mozilla.org/en-US/Firefox/Releases/43 about this. Waiting for some details in response to c#13 before deciding what else to update.

Comment 15

[Benjamin Smedberg]

I don't understand the question. Plugins were run in multi-process mode by default. This change is removing the old hidden prefs that let you switch back to single-process mode.

Comment 16

[Eric Shepherd [:sheppy]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #15)
> I don't understand the question. Plugins were run in multi-process mode by
> default. This change is removing the old hidden prefs that let you switch
> back to single-process mode.

OK, the real question I meant to ask and didn't:

If you've disabled e10s, do plugins still run in multi-process mode? Are there implications to that which devs might need to know about?

Comment 17

[Tony Mechelynck [:tonymec]]

IIUC, plugins (other than Acrobat Reader, which however has its own separate process IIUC) have been run in a separate "plugin-container" process for a long time. Again IIUC, it was the success of this plugin-container model which later made developers think of applying it also to non-plugin operations within the browser itself: this was dubbed electrolysis and abbreviated e10s.

But I don't pretend that I understand all the ins and outs of e10s. So: Benjamin, if I'm distorting reality in some important way, please step in; and Eric, did I answer your question?

Comment 18

[Benjamin Smedberg]

The point of this change was to force multi-process plugins. This is preparation for multi-process content but separate.

Comment 19

[Eric Shepherd [:sheppy]]

So, just to be 100% clear, I take this to mean that none of the preferences for e10s, including "Enable multi-process Nightly", have any impact on plugins anymore -- they always run in multi-process mode, and nothing can be done by the user to change it anymore. Correct interpretation?

Comment 20

[Benjamin Smedberg]

Correct.

Comment 21

[Nisse]

Ever since you introduced OOP execution I've gotten choppy playback when watching flash content. If i disabled plugin container everything was fine again. At first I could do it in about:config, but later I had to jump through all sort of hoops in order to shut it down (environment variables). But at least I could shut it down.

Now you've removed the option altogether and HELLO CHOPPY FLASH CONTENT. Thanks a lot, guys.