Asynchronous plugin instantiation

[Benjamin Smedberg]

Plugin instantiation in gecko is asynchronous, e.g.

var p = iframe.contentDocument.createElement('embed');
p.setAttribute('id', 'plugin1');
p.setAttribute('type', 'application/x-test');
p.setAttribute('width', '400');
p.setAttribute('height', '400');
p.setAttribute('drawmode', 'solid');
p.setAttribute('color', 'FF00FFFF');
dump('before appendChild, p.setColor: ' + p.setColor + '\n');
iframe.contentDocument.body.appendChild(p);

dump('after appendChild, p.setColor: ' + p.setColor + '\n');

// force reflow to instantiate the plugin and crash
var f = iframe.contentWindow.getComputedStyle(p, null)
.getPropertyValue("left");
dump('after computedstyle, p.setColor: ' + p.setColor + '\n');

In all three cases, p.setColor is still undefined: the plugin is
instantiated asynchronously, and so when I'm writing plugin tests I use a
setTimeout to wait for this plugin to load.

* Is there a DOM event fired when the plugin actually loads? Trolling
through our sources, I haven't seen anywhere which would fire a load event
(looked through nsObjectLoadingContent::Instantiate mainly).

* If the <embed> is part of the original document, is plugin loading
guaranteed to block the main document onload, even if as in this case there
is no network stream?

--BDS

[Boris Zbarsky]

On 12/22/09 9:59 AM, Benjamin Smedberg wrote:
> * Is there a DOM event fired when the plugin actually loads?

I do not believe so. We could add one.

> * If the <embed> is part of the original document, is plugin loading
> guaranteed to block the main document onload, even if as in this case
> there is no network stream?

Looks like no. We can change this pretty easily, and probably should.

-Boris

[Benjamin Smedberg]

Filed bug 536443.

--BDS