Looks like we are not currently killing the Flash process once we started it. We have reports of UI responsiveness deteriorating over time. There is a good chance this is related to Flash leaking or just falling apart over time (I have seen several lag issues interacting with the menu after FF runs for a while, restart or disabling flash makes this go away). We should try to kill the Flash processes aggressively. This will be tricky in some cases (audio might be playing in a background tab). We might need a white list, or some fancy heuristics here. Considering our UI responsiveness issues, please consider this bug top priority.

Where's the data on flash leaks? The "as possible" bit is the tricky part here. If we kill the flash subprocess while any tabs (background or foreground) have live applets, then we're going to cause compat issues. That raises the first bit of info I'd like to know (1) During what percentage of firefox's runtime does the flash subprocess have 0 live instances? This corresponds to either there not being a flash subprocess, or there being 0 live instances (PluginModuleParent->ManagedPPluginInstance.Length() == 0). Taras, could we get telemetry data for this? If a high percentage of the runtime, flash is kill-able without compat issues, then we're golden. If not, we need another plan. I'm betting that it's generally not safely killable. A gmail app tab, e.g., will prevent it from being killed safely. A page can only notice a flash instance is dead if it tries to interact with it through JS. We can never know when a page will try to poke a plugin, but we can assume it generally happens early in startup. (Could use telemetry again.) So if there are no PluginScriptableObjects for all flash instances, we can assume that it's killable without causing too much trouble. This isn't sound. So second bit of data (2) During what percentage of firefox's runtime does the flash subprocess have 0 live scriptable wrappers? When we know what times we're allowed to kill the flash process, we can hack up heuristics for spacing out full reloads trading off leaks.

If we are talking about killing Flash only when there are no instances of it currently, then this is basically a dup of bug 543376. I don't know of any user-friendly way we could kill Flash while there are instances of it in any currently open tab. Note that we cannot kill it every time we hit 0 instances, because this will shut it down on most page transitions, and starting a new Flash instance has a startup hit which causes jank.

Wrong bug#: bug 501485

We could set a 30 second (straw man) timer when we get to zero instances and when that goes off we can kill the plugin if there are still zero instances. I don't think we've considered that approach before.

Killing periodically, once a day or so, on 0-instance transition, would not hurt if done when the user has been idle for a long time and the hour is late. Think cron jobs on your Unix or Linux based desktops. Leak monitoring would be gravy but we do not have to get fancy. We do need this bug patched. I have Flash on and no adblock add-ons (how many of you do?) and I see performance degrade over time, especially when there's Flash on the page (which is not always obvious). /be

Use Flash regularly, haven't seen any obvious problems on Windows but I do end up restarting for nightly updates pretty regularly and I've got a lot of RAM, so it might not show up.

Flagging for add-on compat, since some add-ons (not many) use Flash components in their code and they could be affected. What would happen in the case I want to, for example, download a large YouTube video and leave it buffering on my system for a long time / overnight? If the plugin is killed during this time, would I lose all the downloaded data and have to start over? Would the player on the page reload and start playing?

(In reply to Jorge Villalobos [:jorgev] from comment #7) > What would happen in the case I want to, for example, download a large > YouTube video and leave it buffering on my system for a long time / > overnight? If the plugin is killed during this time, would I lose all the > downloaded data and have to start over? Would the player on the page reload > and start playing? I don't think we would consider killing the Flash process while it had > 0 instances running. In the case you typed out there would be at least one Flash instance, so we wouldn't consider killing the process.

(In reply to Josh Aas (Mozilla Corporation) from comment #8) > (In reply to Jorge Villalobos [:jorgev] from comment #7) > I don't think we would consider killing the Flash process while it had > 0 > instances running. In the case you typed out there would be at least one > Flash instance, so we wouldn't consider killing the process. I thought comment 2 and comment 3 clarified that this bug is exactly for this, and otherwise it would be a dupe of bug 501485.

(In reply to Chris Jones [:cjones] [:warhammer] from comment #1) > (1) During what percentage of firefox's runtime does the flash subprocess > have 0 live instances? This corresponds to either there not being a flash > subprocess, or there being 0 live instances > (PluginModuleParent->ManagedPPluginInstance.Length() == 0). Taras, could we > get telemetry data for this? Similarly, some data on the actual memory usage of plugins would be fantastic. Clearly a separate bug, so I went ahead and filed bug 700934!

My current plan for this bug is to kill the Flash plugin if it has been alive for more than 6 hours the next time we hit 0 instances. We also will continue to kill it earlier if it is unused for more than N minutes (currently 3 I think).

(In reply to Benjamin Smedberg [:bsmedberg] from comment #11) > My current plan for this bug is to kill the Flash plugin if it has been > alive for more than 6 hours the next time we hit 0 instances. We also will > continue to kill it earlier if it is unused for more than N minutes > (currently 3 I think). Benjamin, do you still plan to kill the plugin process when it hits 0 SWF instances? This is a small code change, but it could cause more jank if Firefox must frequently respawn a new plugin process.

Current unloadTimeoutSecs is 30. I thought we had PLUGIN_STARTUP_MS to measure how many restarts this was causing, but it turns out this was removed at some point. Also I'm a little worried that unloadTimeoutSecs may not work properly with e10s, because the instances are managed by the content process(es), but the plugin itself is managed by the parent. I'm going to file a separate bug about that. I'm not worried about the jank: a little startup jank every 6 hours is much better than gradual slowing of the entire system over time as Flash leaks memory.

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