All users were logged out of Bugzilla on October 13th, 2018

XBL constructor called after element instantiation

NEW
Unassigned

Status

()

14 years ago
9 years ago

People

(Reporter: vlad, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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).
Created attachment 186264 [details] [diff] [review]
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.
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?
Assignee: xbl → nobody
QA Contact: ian → xbl
You need to log in before you can comment on or make changes to this bug.