Because plugin instantiation is asynchronous, and we're planning on making even more asynchronous in bug 522573, we should make sure that plugin loading blocks page onload, and that pages can be notified when plugins actually do load with a load event. bz/smaug, can one of you take this?
So we actually want an event that fires when instantiation is complete, right?
Yes. There are two possible definitions of "complete", though: * NPP_New has been called (the plugin is fully scriptable now) * NPP_New has been called and the initial plugin stream from <embed src="foo"> has finished loading. I think the latter makes more sense given the parallels with the load event fired at <img src="foo">, but I really only need the former because all I'm dealing with is scripting. Something to bring up in whatwg or plugin-futures, perhaps? ugh.
For something like a youtube video, does the initial plugin stream finish before the video finishes buffering?
Yes, the initial stream is the .swf file. But I'm pretty sure the plugin opens additional streams from within NPP_New, so those might block onload independently.
Which onload? The page one, or the plug-in one?
The page one. I'm not sure what we should do about the plugin onload.
With the current plugin situation and this bug already sitting around for years it's unlikely that we will still fix that. Anyone seeing that differently or can we close as WONTFIX?
I still think that it will be important for plugin streams and instances to block the page onload in order for async plugin instantiation to have a fighting chance and not cause huge regressions. The plugin-specific load event is probably not so valuable.
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.