297717 - XBL constructor called after element instantiation

Status: RESOLVED WONTFIX

(Core :: XBL, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

The attached testcase creates a number of elements that have an XBL binding from
the constructor of another XBL element.  After calling appendChild on a node in
the current document, the second element is instantiated, and properties can be
set on it.  However, its constructor isn't called until some point later (which
overwrites the values explicitly set via properties with default initialization
values).

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: xbl testcase

Untar somewhere, navigate to xbl1.xul.	The display should have Index 0 through
4, instead it only has 5 instances of Index 0.	The dump()s should provide more
information on the order things are called in.

Comment 2

[Boris Zbarsky [:bzbarsky]]

So the problem is that we don't reenter constructor processing while a
constructor is executing, right?  I bet the following code is responsible:

748 NS_IMETHODIMP
749 nsBindingManager::ProcessAttachedQueue()
750 {
751   if (mProcessingAttachedStack)
752     return NS_OK;

Note that assuming sync XBL binding instantiation is generally dangerous -- sync
binding instantiation is not guaranteed by XBL...

In any case, that reentry guard fixes a crash (bug 207617), so just removing it
without replacing it with equivalent crash-protection is not really an option...
 Perhaps we should save off the attached queue into a stack local and then clear
it before processing (and remove the reentry guard)?  Or will that reintroduce
bug 207617 due to the stack space growth from the local?

Comment 3

[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.