Closed Bug 1194780 Opened 9 years ago Closed 9 years ago

Remove support for in-process plugins

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla43

People

(Reporter: benjamin, Assigned: benjamin)

References

Details

(Keywords: dev-doc-needed)

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: nobody → benjamin
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.
@patwonder What is your opinion?
Flags: needinfo?(patwonder)
If it is removed, will FireIE addon still work properly? Is there a solution?
(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)
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
Closed: 9 years ago
status-firefox43: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
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 → ---
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)
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → FIXED
Depends on: 1163049
Depends on: 1200361
Depends on: 1196115
No longer depends on: 1163049
Target Milestone: --- → mozilla43
Benjamin, should this have a release note?
Flags: needinfo?(benjamin)
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.
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?
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?
Correct.
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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.