Jared Stafford Reporter
	Description • 11 years ago

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.

	Mihai Morar, (:MihaiMorar)
	Comment 1 • 11 years ago

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.

	Benjamin Smedberg
	Comment 2 • 11 years ago

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.

	Jared Stafford Reporter
	Comment 3 • 11 years ago

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.

	Jared Stafford Reporter
	Comment 4 • 11 years ago

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.

	John Schoenick [:johns] Assignee
	Comment 5 • 11 years ago

This was probably regressed by bug 418615. about:addons needs a better way to disable plugins

	Benjamin Smedberg
	Comment 6 • 10 years ago

gfritzsche/johns, either of you care to mentor this and point a potential contributor at how to fix this?

	John Schoenick [:johns] Assignee
	Comment 7 • 10 years ago

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.

	Georg Fritzsche [:gfritzsche]
	Comment 8 • 10 years ago

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.

	Benjamin Smedberg
	Comment 9 • 10 years ago

That sounds right to me, especially because we have a list via nsPluginHost.mInstances. johns is that ok?

	John Schoenick [:johns] Assignee
	Comment 10 • 10 years ago

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.

	John Schoenick [:johns] Assignee
	Comment 11 • 10 years ago

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.

	BMO Automation
	Comment 12 • 3 years ago

Resolving as wont fix, plugin support deprecated in Firefox 85.