559811 - Binding load order changed in 1.9.2 compared to previous versions

Status: RESOLVED INVALID

(Core :: XBL, defect)

Description

[Neil Stansbury]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2
Build Identifier: 

See Bug 526178 - This is a re-filing of this bug

Post 1.9.2b1 a binding executes its own constructor before other bindings defined in it's anonymous content. This prevents the outer constructor from addressing anonymous content as those bindings haven't been constructed yet.

Changing the test case of the original bug slightly:

<bindings xmlns="http://www.mozilla.org/xbl" xmlns:xbl="http://www.mozilla.org/xbl" xmlns:html="http://www.w3.org/1999/xhtml" xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

	<binding id="bindinga">
		<content>
			<xul:bindingb/>
			<xul:bindingc/>
		</content>
		<implementation>
			<constructor><![CDATA[
				alert("constructing A");			
			]]></constructor>
		</implementation>
	</binding>
	
	<binding id="bindingb">
		<implementation>
			<constructor><![CDATA[
				alert("constructing B");			
			]]></constructor>
		</implementation>
	</binding>

	<binding id="bindingc">
		<implementation>
			<constructor><![CDATA[
				alert("constructing C");			
			]]></constructor>
		</implementation>
	</binding>
	
</bindings>

Reproducible: Always

Actual Results:  
Post 1.9.2b2 and after Bug 526178 the construction order is now A, B, C

Expected Results:  
Pre 1.9.2b2 the construction order was B, C, A

This would be the correct order given the outer constructor of a binding should be able to access it's inner anonymous content during execution.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> See Bug 526178 - This is a re-filing of this bug

No, this is apparently a request to back out the patch for that bug...  why, exactly?

> Post 1.9.2b1 a binding executes its own constructor before other bindings
> defined in it's anonymous content.

Yes.  This is the 1.9.1 behavior as well.  And 1.9.0, and 1.8.1.

> Post 1.9.2b2 and after Bug 526178 the construction order is now A, B, C

No, it's A, C, B.  Did you even test your code?  It's also A, C, B in Firefox 2, Firefox 3, and Firefox 3.5.

> given the outer constructor of a binding should be able to access it's inner
> anonymous content during execution

XBL1 has never made such a guarantee, and in fact hasn't behaved like this in years (and probably never; certainly the oldest nightly I have on hand, from March 2004 and with the "Firebird" branding, Gecko version 1.7alpha or so, has the same behavior: A, C, B).

Comment 2

[Boris Zbarsky [:bzbarsky]]

And just to be clear, sometime between 1.9.1 and 1.9.2b1 the order was changed by accident.  Bug 526178 was about restoring the 1.9.1 behavior.  This bug seems to be about going back to the incorrect 1.9.2b1 behavior, hence invalid.

Comment 3

[Neil Stansbury]

Boris,

I don't know why you're so indignant about this bug.

I posted a reply to *your* post re: Bug 526178 on m.d.t.xbl querying the "fixed" behaviour.  With no reply from anyone (yourself included) a month later I filed this bug with the best knowledge that I had.

I made what seemed a reasonable assumption that an anonymous child would be constructed before it's parent in any shadow tree, which was obviously incorrect.

I accept that had I tried the test on the 1.9.1 branch and prior then I would have seen the same behaviour.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Neil, I'm not being indignant.  I'm sorry if it came across that way....

I did reply to your original post on m.d.t.xbl, for what it's worth, but it looks like it didn't come through because I made the mistake of attaching a XUL testcase to the post.  So there was a serious communication failure on my part here, for which I apologize.

Comment 5

[Neil Stansbury]

Hi Boris,

No problem - thanks for the apology - it seems we "crossed in the post" so to speak.

I seem to have managed to code my assumptions into the only XULRunner build where my assumptions would have been correct! Ce la vie.