394676 - XBL constructors fire after window.onload event

Status: RESOLVED FIXED

(Core :: XBL, defect)

Description

[Chris Burnette]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a7) Gecko/2007090203 Minefield/3.0a7

Starting around Firefox 3 Alpha 3, XBL constructors started firing after the window.onload event. Prior to that, XBL constructors fire before the window.onload event. 

Because of this, XBL bindings cannot hook into the window.onload event.

I've tested this under both Linux and Windows OS's.

Reproducible: Always

Steps to Reproduce:
Save the attached files (xbl_test.htm and xbl_test.xml) to your computer and open the HTML file with Firefox Alpha 3 or higher (at least through Alpha 7)

Actual Results:  
You should see at the top of the page:
window.onload,constructor:id5,constructor:id4,constructor:id3,constructor:id2,constructor:id1

which is the order that these events occured in. Not that the window.onload event is first and that the onload listeners installed by the constructors never fire since the window.onload fired before the constructors were called.

Expected Results:  
Under Firefox 2.x, you see:

constructor:id1,constructor:id2,constructor:id3,constructor:id4,constructor:id5,window.onload,window.onload:id1,window.onload:id2,window.onload:id3,window.onload:id4,window.onload:id5

Comment 1

[Chris Burnette]

Attachment: XBL HTML Test file

This file illustrates the problem (along w/ the xbl_test.xml file).

Comment 2

[Chris Burnette]

Attachment: XBL Binding Test file

This file illustrates the problem (along w/ the xbl_test.htm file).

Comment 3

[Boris Zbarsky [:bzbarsky]]

The patch in bug 394014 will fix this.

That said, I tried to write a mochitest for this and discovered that the bug disappeared; something mochitest is doing is perturbing the test document to cause an extra begin/end update before any load events I can attach fire.  I've ended up writing a reftest for this...

Comment 4

[Boris Zbarsky [:bzbarsky]]

Fixed by checkin for bug 394014.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Branch patch attached to bug 267833 as part of the big branch patch there.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Fixed on branch by checkin for bug 267833.

I thought about it some more, and we should also add some robustness stuff on trunk...

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: Like so (trunk patch)

Comment 8

[Boris Zbarsky [:bzbarsky]]

Checked that in on trunk.

Comment 9

[Martijn Wargers (dead)]

With Firefox2.0.0.7, I get:
constructor:id1,constructor:id2,constructor:id3,constructor:id4,constructor:id5,window.onload,window.onload:id1,window.onload:id2,window.onload:id3,window.onload:id4,window.onload:id5

But with using 2007-10-04 1.8 branch build I get:
constructor:id5,constructor:id4,constructor:id3,constructor:id2,constructor:id1,window.onload,window.onload:id5,window.onload:id4,window.onload:id3,window.onload:id2,window.onload:id1

I guess that means this is fixed on the 1.8 branch? (although constructors still seem to have fired before onload)

Comment 10

[Boris Zbarsky [:bzbarsky]]

This didn't regress on branch, because I rolled the fix into the branch fix for the bug that regressed it.  It needs verifying as not having regressed, though.

Comment 11

[Martijn Wargers (dead)]

Well, I guess it didn't regress on the branch then, since all the constructors fired before window.onload as I noted in comment 9.
The constructor order seems to have changed, though.

On current trunk build, I get:
constructor:id5,constructor:id4,constructor:id3,constructor:id2,constructor:id1,window.onload,window.onload:id5,window.onload:id4,window.onload:id3,window.onload:id2,window.onload:id1

Comment 12

[Boris Zbarsky [:bzbarsky]]

Yeah, the firing order of the constructors changed.  That's fine, as far as I'm concerned: no ordering of separate async loads is guaranteed.

Comment 13

[Martijn Wargers (dead)]

Ok, thanks Boris. Marking verified1.8.1.8.