See testcase, which crashes current trunk build directly, or after a reload. The bindings (wrapped in data urls are 2 setting position:fixed in the constructor and 1 empty binding. This regressed between 2007-09-14 and 2007-09-15: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-09-14+04&maxdate=2007-09-15+09&cvsroot=%2Fcvsroot I guess a regression from bug 394014, somehow? http://crash-stats.mozilla.com/report/index/965f71f8-63ae-11dc-a4b8-001a4bd46e84 0 nsIFrame::GetPositionIgnoringScrolling() mozilla/layout/generic/nsIFrame.h:718 1 nsHTMLReflowState::CalculateHypotheticalBox(nsPresContext*, nsIFrame*, nsIFrame*, int, int, nsHTMLReflowState const*, nsHypotheticalBox&) mozilla/layout/generic/nsHTMLReflowState.cpp:1062 2 nsHTMLReflowState::InitAbsoluteConstraints(nsPresContext*, nsHTMLReflowState const*, int, int) mozilla/layout/generic/nsHTMLReflowState.cpp:1112 3 nsHTMLReflowState::InitConstraints(nsPresContext*, int, int, nsMargin const*, nsMargin const*) mozilla/layout/generic/nsHTMLReflowState.cpp:1803 4 nsHTMLReflowState::Init(nsPresContext*, int, int, nsMargin const*, nsMargin const*) mozilla/layout/generic/nsHTMLReflowState.cpp:315 5 nsHTMLReflowState::nsHTMLReflowState(nsPresContext*, nsHTMLReflowState const&, nsIFrame*, nsSize const&, int, int, int) mozilla/layout/generic/nsHTMLReflowState.cpp:180 6 nsAbsoluteContainingBlock::ReflowAbsoluteFrame(nsIFrame*, nsPresContext*, nsHTMLReflowState const&, int, int, nsIFrame*, unsigned int&, nsRect*) mozilla/layout/generic/nsAbsoluteContainingBlock.cpp:369 7 nsAbsoluteContainingBlock::Reflow(nsIFrame*, nsPresContext*, nsHTMLReflowState const&, int, int, int, int, nsRect*) mozilla/layout/generic/nsAbsoluteContainingBlock.cpp:159 8 nsBlockFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) mozilla/layout/generic/nsBlockFrame.cpp:1138 9 nsAbsoluteContainingBlock::ReflowAbsoluteFrame(nsIFrame*, nsPresContext*, nsHTMLReflowState const&, int, int, nsIFrame*, unsigned int&, nsRect*) mozilla/layout/generic/nsAbsoluteContainingBlock.cpp:375 10 nsAbsoluteContainingBlock::Reflow(nsIFrame*, nsPresContext*, nsHTMLReflowState const&, int, int, int, int, nsRect*) mozilla/layout/generic/nsAbsoluteContainingBlock.cpp:159 etc..

The comments explain what's going on. Martijn, do you think you can create a reliably crashing testcase for the tests? Your testcase does crash for me 100% on load, but your comment makes it sound like it doesn't always for you? The key here would be that after the constructor for a binding that sets "position: fixed" on a node that started "position: absolute" runs, we need to do a reflow that moves that node's placeholder to the next line... Shouldn't need the other two bindings and all that, I would think, though you might have to flush out reflow before creating the node with the binding or something.

And yes, regression from bug 394014.

(In reply to comment #1) > Martijn, do you think you can create a reliably crashing testcase for the > tests? Your testcase does crash for me 100% on load, but your comment makes it > sound like it doesn't always for you? I tried it 5 times with the online testcase, only 1 time it didn't crash directly, but only after a reload, so I think that's probably reliable enough.

What if the second round of style changes causes XBL constructors to be queued up again? Should we actually be using a loop here?

There is no guarantee a loop would terminate. There's also no real reason to run such newly-queued ctors here, imo.

Comment on attachment 281151 [details] [diff] [review] Proposed fix yeah OK. But add a comment mentioning that some XBL constructors may still be pending and that we're just ignoring them because that's safer and it's not worth processing them.

Checked in, with test.

Verified fixed, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007091804 Minefield/3.0a8pre