407311 - Need a way to know when an XBL-bound node is ready

Status: RESOLVED WONTFIX

(Core :: XBL, defect)

Description

[Wladimir Palant]

TomTom HOME code currently makes the assumption that XBL bindings bind synchronously. This means that we do things like:

var iframe = document.createElementNS(XULNS, "iframe");
container.appendChild(iframe);
iframe.contentWindow.addEventListener(...);

Now the property contentWindow is defined in the XBL binding, if the binding doesn't apply immediately when the node is inserted in the document this code will break. And we already found some cases where this in fact happens and have to use hacks to work around them - there seems to be no proper way to see when an XBL-bound node is ready to be used.

Proposal: fire events bindingattached/bindingdetached (not bubbling) in addition to calling constructor/destructor of the binding. Then the code above can be changed into:

var iframe = document.createElementNS(XULNS, "iframe");
iframe.addEventListener("bindingattached", function() {
  this.contentWindow.addEventListener(...);
}, false);
container.appendChild(iframe);

Comment 1

[Neil Deakin]

Is this the same as bug 367400?

Comment 2

[Wladimir Palant]

No, this bug is different. I want real events to be fired after the constructor of the binding so that whoever created the node knows that it is ready to be used. Right now the only way to achieve this is to change the constructor of the binding, but often you have no access to it.

Comment 3

[Martijn Wargers (dead)]

Afaik, chrome bindings are loaded synchronously, so that would mean that's not the problem.
Is there a particular testcase that's failing?

Comment 4

[Wladimir Palant]

> Afaik, chrome bindings are loaded synchronously

Can this be relied on?

The test scenario is the following: we insert a <xul:iframe> into a document from the unload handler of another <xul:iframe> (it is being removed from the same document). Bindings used to load synchronously in this case (1.9a7), they do no longer. Workaround was to call addBinding() explicitly before inserting the node into the document (not exactly a good solution). I will try to put together a real testcase a later.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Chrome bindings load synchronously.  The constructor is not guaranteed to run then, however; if a binding load is performed in the middle of an update the constructor won't run until the end of the update.

Comment 6

[Wladimir Palant]

Attachment: Testcase

See testcase - if you click "Add frame" the code will be denied access to contentWindow of the new frame (but it is initialized, so everything is fine). If you click "Add frame while removing" which will create a new frame from the unload handler of the existing one you will see that contentWindow is undefined (recent Minefield nightlies only, Firefox 2.0 will show same behavior as in the previous case). Is this the expected behavior or a bug? And if it is expected, how should I change the code if I want to work with the frame I created?

Comment 7

[Martijn Wargers (dead)]

Wladimir, thanks for the testcase.
Just to be sure I understand, the testcase needs to be run from chrome://, right? (which in that case, it seems to be worksforme). Otherwise you would hit bug 379395, I think.

Comment 8

[Wladimir Palant]

No, it works fine from HTTP. On HTTP you see the message "access to frame.contentWindow denied" (bug 379395) but that's only another indication that the binding is ready. However, when you click "Add frame while removing" you get "frame.contentWindow is undefined" - which means that we are accessing the field before the binding was applied. That's the actual problem here, and still reproducible with 1.9b3pre Gecko/2007121305.

Comment 9

[Boris Zbarsky [:bzbarsky]]

The basic problem that testcase highlights is that we fire the unload handler at a "bad" time.  We have existing bugs covering that.

Comment 10

[Boris Zbarsky [:bzbarsky]]

XBL is now disabled in Firefox (Bug 1583314) and is in the process of being removed from Gecko (Bug 1566221), so closing bugs requesting changes to its implementation as wontfix.