Remove support for in-process plugins

RESOLVED FIXED in mozilla43

Status

()

RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: benjamin, Assigned: benjamin)

Tracking

({dev-doc-needed})

unspecified
mozilla43
dev-doc-needed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

3 years ago
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?
Flags: needinfo?(jaas)
(Assignee)

Updated

3 years ago
Assignee: nobody → benjamin
(Assignee)

Updated

3 years ago
Duplicate of this bug: 1156516

Comment 2

3 years ago
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

3 years ago
@patwonder What is your opinion?
Flags: needinfo?(patwonder)

Comment 4

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

Comment 5

3 years ago
(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.
Flags: needinfo?(patwonder)

Comment 7

3 years ago
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
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox43: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla43

Comment 8

3 years ago
Actually, it seems they were about bug 874167, right? Very sorry for the noise.
Status: RESOLVED → REOPENED
status-firefox43: fixed → ---
Resolution: FIXED → ---
Target Milestone: mozilla43 → ---

Comment 9

3 years ago
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.
Flags: needinfo?(jaas)
(Assignee)

Updated

3 years ago
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
Resolution: --- → FIXED
(Assignee)

Updated

3 years ago
Depends on: 1163049
(Assignee)

Updated

3 years ago
Depends on: 1200361
(Assignee)

Updated

3 years ago
Depends on: 1196115
(Assignee)

Updated

3 years ago
No longer depends on: 1163049

Updated

3 years ago
Target Milestone: --- → mozilla43
Benjamin, should this have a release note?
Flags: needinfo?(benjamin)
(Assignee)

Comment 11

3 years ago
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.
Flags: needinfo?(benjamin)
Adding "dev-doc-needed" as it would be good to have something to link to from the release notes.
Keywords: dev-doc-needed
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.
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.
(Assignee)

Comment 15

3 years ago
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.
(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?
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?
(Assignee)

Comment 18

3 years ago
The point of this change was to force multi-process plugins. This is preparation for multi-process content but separate.
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?
(Assignee)

Comment 20

3 years ago
Correct.

Comment 21

3 years ago
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.
You need to log in before you can comment on or make changes to this bug.