Closed Bug 890059 Opened 8 years ago Closed 5 months ago

Disabling a plugin does not stop current instances

Categories

(Core :: Plug-ins, defect, P3)

22 Branch
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jspenguin, Assigned: johns)

References

Details

(Whiteboard: [p=8][qa+])

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

1. Go to a website that uses Shockwave Flash (e.g. YouTube). Verify that the flash plugin is being used by right-clicking on the video area and checking that "About Adobe Flash Player" is included in the context menu.
2. Open the Add-ons manager (Ctrl+Shift+A). Go to the Plugins tab and disable "Shockwave Flash"


Actual results:

The running plugin is not stopped until the containing tab is reloaded or closed.


Expected results:

The plugin is stopped immediately, like in previous versions.
I think this is by design. Adding Georg who has more experience on Plugins, and can probably help more here. 

Same results for: having a plugin disabled and Go to AMO and enable it.
Component: Untriaged → Plug-ins
Product: Firefox → Core
I really don't think that we ever stopped plugins immediately, although I may have missed a codepath. Note also bug 883404, which is similar with the CtP UI.
In versions of Firefox prior to 22.0, when I disable plugins either through the Add-ons manager or through an extension (https://addons.mozilla.org/en-US/firefox/addon/flashtoggle/), the plug-in stops immediately.

I have a workaround for now, which is to manually terminate the plugin container process, but this causes Firefox to think that the plugin crashed.
Actually, the extension I mentioned in my previous comment was an old one. The one I currently use is https://addons.mozilla.org/en-US/firefox/addon/flashdisable/. A comment on that page also confirms the previous and current behavior.
This was probably regressed by bug 418615. about:addons needs a better way to disable plugins
Blocks: 418615
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
gfritzsche/johns, either of you care to mentor this and point a potential contributor at how to fix this?
Flags: needinfo?(jschoenick)
Flags: needinfo?(georg.fritzsche)
Flags: firefox-backlog+
Whiteboard: [p=8][qa+]
The way to handle this is similar to pressing 'block' in the doorhanger in CTP mode - call object.reload() on all instances of that plugin. I'm not familiar enough with how the about:addons and frontend CTP stuff work to describe exactly how/where it should be done though.
Flags: needinfo?(jschoenick)
I'm pretty sure that we don't want the addon manager or other frontend code walk through all active instances.
Instead we can have nsPluginTags & nsPluginHost do this. Sound good?

Happy to mentor it with this out of the way.
Flags: needinfo?(georg.fritzsche)
That sounds right to me, especially because we have a list via nsPluginHost.mInstances. johns is that ok?
Flags: needinfo?(jschoenick)
That works, but the existing code in nsPluginHost for stopping instances is bad and not properly re-entrance aware. IIRC we removed the non-shutdown cases where it was used, so this will need more care than just calling DestroyRunningInstances.
Flags: needinfo?(jschoenick)
And I'm rewriting a good chunk of pluginhost instance management in bug 641685 anyway, so I think I'll just take this and make sure the result works right.
Status: NEW → ASSIGNED
Depends on: e10s-plugin-ipc
Assignee: nobody → jschoenick
OS: Windows 7 → All
Hardware: x86_64 → All
Resolving as wont fix, plugin support deprecated in Firefox 85.
Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.