828103 - Display plugin hang ui when GeckoChildProcessHost::SyncLaunch takes too long

Status: RESOLVED WONTFIX

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

Description

[(No longer employed by Mozilla) Aaron Klotz]

vladan hit a 15 second hang while loading a plugin (see URL for profile). Looks like it happened while launching plugin-container. taras suggested that this would also be a good place to fire up the Plugin Hang UI.

This is possible if we were to add a ShouldContinueFromReplyTimeout-like callback to GeckoChildProcessHost::SyncLaunch.

Comment 1

[Vladan Djeric (:vladan)]

Benjamin, could we make this call on a helper thread? It's just instantiating the plugin container, right? Would that violate any plugin semantics?

Comment 2

[Benjamin Smedberg]

What call? We don't create the plugin until we need to use it, and then we need it synchronously (some content expects to be able to script a plugin as soon as its in the DOM tree, unfortunately).

Comment 3

[Vladan Djeric (:vladan)]

Sorry, I meant the CreateNPAPIPlugin call. Couldn't we pause parsing of a page once we hit a Flash object (assuming Flash plugin hasn't been loaded yet) and load the plugin asynchronously while the main event loop handles the chrome UI and deals with other tabs?

Comment 4

[Benjamin Smedberg]

If the plugin comes as a result of parsing... maybe. I don't actually know how any of that works. If the plugin is created programmatically (which is quite common), then we'd have to suspend the stack or something. I believe we can't do anything like that. I don't think that bug 715376 would help with this either, unless it lets you spin a nested event loop and filter/suspend all of the events for the current page.

Comment 5

[Boris Zbarsky [:bzbarsky]]

We could effectively pretend there was a packet boundary after </object> or <embed>, yeah.  But as Benjamin says, that doesn't help for scripted insertions...

Comment 6

[Vladan Djeric (:vladan)]

Ok, I'll need to do a bit of research to get an idea of the proportion of plugin loads from HTML on popular sites.

What about stopping plugins asynchronously? For example, today I ran into a jank where nsDocShell::Destroy triggered nsNPAPIPluginInstance::Stop and the main thread ended up waiting for 117 ms in RPCChannel::WaitForNotify. If we made the Stop call on a helper thread, would that violate any assumptions? e.g. would it be safe to create a new instance from the main thread before the Stop call returned on the helper thread?

Maybe we should continue this discussion on IRC?

Comment 7

[Vladan Djeric (:vladan)]

I don't think we have to worry about scripts when unloading plugin instances off the main thread. We can just return from the "unload" call immediately instead of suspending the stack

Comment 8

[Georg Fritzsche [:gfritzsche]]

(In reply to Vladan Djeric (:vladan) from comment #6
> What about stopping plugins asynchronously?

Note that plugins can call back into the browser and trigger scripts from NPP_Destroy()).

Comment 9

[Benjamin Smedberg]

Making the calls from other threads doesn't make much sense. I have wondered whether we could make the close call asynchronously. If we do that there's going to be a fair bit of state-machine work we'd have to do to prevent incoming calls on that instance from causing instability. We'd basically have to add a signal (such as nulling out PluginInstanceParent::mNPP) that indicates that the instance is "dead". And then in every message receiver we'd have to dead-check and do an appropriate error fallback.

Also for windowed plugins, we'd be destroying the plugin window at some point during this process (I'm not sure exactly where) and so we'd have to make sure that the sequence of events is reasonable.

Finally, the Flash player is certainly making calls back into the page during shutdown, and so it's possible that making those calls fail could cause the plugin to stop saving state correctly or do other weird things. It's hard to know in advance what might happen.

Comment 10

[BMO Automation]

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