Open Bug 289827 Opened 20 years ago Updated 2 years ago

opening calendar's event dialog asserts

Categories

(Core :: Layout, defect)

x86
Linux
defect

Tracking

()

People

(Reporter: mvl, Unassigned)

Details

(Whiteboard: [reflow-refactor])

Attachments

(3 files)

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.
Attached file stack (deleted) —
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.
Summary: opening calendar's event dialog asserts → opening calendar's event dialog asserts
Attached file reduced eventDialog.xul (deleted) —
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.
And all timepicker.xbl has to contain is a <menulist editable="true">. withouth the editable, the assertion goes away.
I'm afraid to say that this looks like a job for Boris...
Attached file testcase (deleted) —
This zip includes the datetimepicker files, reduced as far as i could get it. No need to have calendar installed.
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.
Whiteboard: [reflow-refactor]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: