Closed
Bug 1231306
Opened 10 years ago
Closed 10 years ago
[e10s] Remote process doesn't immediately change Flash plugin state when I set it to "Always Activate"
Categories
(Core Graveyard :: Plug-ins, defect)
Core Graveyard
Plug-ins
Tracking
(e10sm8+, firefox45 fixed, firefox46 fixed)
RESOLVED
FIXED
mozilla46
People
(Reporter: arni2033, Assigned: billm)
References
()
Details
Attachments
(1 file)
5.64 KB,
patch
|
jimm
:
review+
Sylvestre
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
>>> My Info: Win7_64, Nightly 45, 32bit, ID 20151206030448
STR:
1. Open "about:addons", set Shockwave Flash 19.0.0.245 to "Never Activate"
2. Restart the browser
3. Open https://www.mozilla.org/en-US/ in a new tab
4. Open "about:addons" (or switch to opened tab), set Flash to "Always Activate"
5. Open https://www.youtube.com/v/SzmLYHsAcZQ&start=83&end=127 (flash) in a new tab
Result:
There's a prompt window "What should Nighly do with this file?"
Expectations:
The flash player should load.
Workaround:
To kill the remote process (or close all remote tabs), then open flash player in a new tab.
Note that if dom.ipc.processCount is set to > 1, then you can only hope that when you kill a process,
the new tab will be opened in a new process.
Updated•10 years ago
|
Flags: needinfo?(jmathies)
![]() |
||
Comment 1•10 years ago
|
||
Sounds like an e10s blocker. Removing my ni so this falls into our triage list.
tracking-e10s:
? → ---
Flags: needinfo?(jmathies)
![]() |
||
Updated•10 years ago
|
tracking-e10s:
--- → ?
Updated•10 years ago
|
Assignee: nobody → wmccloskey
Assignee | ||
Comment 2•10 years ago
|
||
I can reproduce this.
Assignee | ||
Comment 3•10 years ago
|
||
There were some bookkeeping issues here. The content process frequently sends up queries asking for the current list of plugins. Both the parent and child record an "epoch" value, which is an integer that changes whenever the list of plugins changes. The parent will not send down a new list of plugins if the child's epoch value is the same as the parent's--in this case, the two lists are already synchronized.
One problem here is that we weren't updating the epoch when changing the enabled state of a plugin. Another problem is that enabling a plugin should cause us to register it with the category manager so that it can be used as a "full page plugin" (typically only used for Acrobat or if you navigate directly to an .flv file). The child process was not doing the category manager registration.
Attachment #8701659 -
Flags: review?(jmathies)
![]() |
||
Updated•10 years ago
|
Attachment #8701659 -
Flags: review?(jmathies) → review+
Comment 5•10 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 10 years ago
status-firefox46:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
Assignee | ||
Comment 7•10 years ago
|
||
Comment on attachment 8701659 [details] [diff] [review]
patch
We'd like to land this for the beta 45 experiment. It's been in for a while and is low risk.
Approval Request Comment
[Feature/regressing bug #]: e10s
[User impact if declined]: fullscreen plugins may not work
[Describe test coverage new/current, TreeHerder]: on m-c
[Risks and why]: low
[String/UUID change made/needed]: none
Attachment #8701659 -
Flags: approval-mozilla-aurora?
Comment 8•10 years ago
|
||
Comment on attachment 8701659 [details] [diff] [review]
patch
Taking it for the experiment
Attachment #8701659 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 9•10 years ago
|
||
bugherder uplift |
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•