Open
Bug 289827
Opened 20 years ago
Updated 2 years ago
opening calendar's event dialog asserts
Categories
(Core :: Layout, defect)
Tracking
()
NEW
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.
Reporter | ||
Comment 1•20 years ago
|
||
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
Reporter | ||
Comment 3•20 years ago
|
||
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.
Reporter | ||
Comment 4•20 years ago
|
||
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...
Reporter | ||
Comment 6•20 years ago
|
||
This zip includes the datetimepicker files, reduced as far as i could get it.
No need to have calendar installed.
Comment 7•20 years ago
|
||
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]
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•