XBL constructors fire after window.onload event

RESOLVED FIXED

Status

()

Core
XBL
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: Chris Burnette, Assigned: bz)

Tracking

({regression, verified1.8.1.8})

unspecified
x86
All
regression, verified1.8.1.8
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1.8 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

10 years ago
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
(Reporter)

Comment 1

10 years ago
Created attachment 279380 [details]
XBL HTML Test file

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

Comment 2

10 years ago
Created attachment 279381 [details]
XBL Binding Test file

This file illustrates the problem (along w/ the xbl_test.htm file).
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...
Assignee: nobody → bzbarsky
Blocks: 267833
Status: UNCONFIRMED → NEW
Depends on: 394014
Ever confirmed: true
Keywords: regression
Fixed by checkin for bug 394014.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Branch patch attached to bug 267833 as part of the big branch patch there.
Flags: blocking1.8.1.8+
Fixed on branch by checkin for bug 267833.

I thought about it some more, and we should also add some robustness stuff on trunk...
Keywords: fixed1.8.1.8
Created attachment 283231 [details] [diff] [review]
Like so (trunk patch)
Attachment #283231 - Flags: superreview?(jonas)
Attachment #283231 - Flags: review?(jonas)
Depends on: 398289
Attachment #283231 - Flags: superreview?(jonas)
Attachment #283231 - Flags: superreview+
Attachment #283231 - Flags: review?(jonas)
Attachment #283231 - Flags: review+
Attachment #283231 - Flags: approval1.9+
Checked that in on trunk.
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)
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.
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
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.
Ok, thanks Boris. Marking verified1.8.1.8.
Keywords: fixed1.8.1.8 → verified1.8.1.8
You need to log in before you can comment on or make changes to this bug.