289827 - opening calendar's event dialog asserts

Status: NEW

(Core :: Layout, defect)

Description

[Michiel van Leeuwen (email: mvl+moz@)]

When opening the new event dialog in calendar, i get a few assertions:
###!!! ASSERTION: Could not find an adaptor!: 'Error', file
/home/michiel/mozhack/tree1/mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 692

and a few messages like:

frame: Area(div)(-1) (0x96ac290) style: 0x96ac204 :-moz-scrolled-content {}
Wrong parent style context:  style: 0x96ac178 :-moz-scrolled-content {}
should be using:  style: 0x96ac02c {}

will attach stack from the assertion.

Comment 1

[Michiel van Leeuwen (email: mvl+moz@)]

Attachment: stack

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Looks like a frame construction issue to me. We need a reduced test case, and
then a frame dump after loading it in the layout debugger.

Comment 3

[Michiel van Leeuwen (email: mvl+moz@)]

Attachment: reduced eventDialog.xul

the <datetimepicker> is what is needed to get the assertion.
datetimepicker.xbl is just a <datepicker> and a <timepicker>. When i remove one
of those, the assertion stays. But if i use <datepicker> or <timepicker> in the
main xul directly, it goes away.

Comment 4

[Michiel van Leeuwen (email: mvl+moz@)]

And all timepicker.xbl has to contain is a <menulist editable="true">. withouth
the editable, the assertion goes away.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm afraid to say that this looks like a job for Boris...

Comment 6

[Michiel van Leeuwen (email: mvl+moz@)]

Attachment: testcase

This zip includes the datetimepicker files, reduced as far as i could get it.
No need to have calendar installed.

Comment 7

[Boris Zbarsky [:bzbarsky]]

What a mess.  We're in the middle of frame construction, and then
FinishBuildingScrollFrame() calls AppendFrames() on the scrollframe (which is a
box).  That triggers ReflowDirtyChild() call, which gets passed up the box
hierarchy (see nsBox::ReflowDirtyChild and the way it calls its parent's
ReflowDirtyChild with itself as the arg) till it gets to an inline frame that
has a parent (and whose parent is in fact a box), but which hasn't been appended
to its parent yet (because we're not done constructing it!).  At this point we
call into the inline's parent (because inlines also pass ReflowDirtyChild
along), which lands us in nsBoxFrame::ReflowDirtyChild.  This tries to find the
kid to reflow in its list, and of course fails.  So it asserts.

The answer, probably, is to not do all this junk for frames that have never been
reflowed...  Marking as reflow-refactor for now since that branch will probably
change a lot of this code.