Closed
Bug 347853
Opened 18 years ago
Closed 18 years ago
Crash [@ nsIView::Destroy] with fixed and relative positioned quote elements and removing styles
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
mozilla1.9alpha1
People
(Reporter: martijn.martijn, Assigned: uriber)
References
Details
(Keywords: crash, regression, testcase, Whiteboard: post 1.8-branch)
Crash Data
Attachments
(3 files)
649 bytes,
text/html
|
Details | |
472 bytes,
text/html
|
Details | |
1.36 KB,
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
See upcoming testcase, which crashes Mozilla when loading it.
This regressed between 2006-07-04 and 2006-07-05.
The only patch that could be responsible for the crash is the patch from bug 343540, I think.
Talkback ID: TB21894378Q
0x00000000
nsIView::Destroy
Marking security sensitive, I guess.
Reporter | ||
Comment 1•18 years ago
|
||
Assignee | ||
Comment 2•18 years ago
|
||
This testcase crashes for me consistently after refreshing once (it does not auto-refresh).
It does not contain <q> elements, and the <blockquote> is replaced with a <div>. Also, only the style on the <dd> is removed.
With this testcase, upon the initial load, I get the following assertion:
###!!! ASSERTION: Allowed only one anonymous view between frames: 'ancestorView == view->GetParent()->GetParent()', file /Users/urib/mozilla/layout/generic/nsContainerFrame.cpp, line 268
(I do not get this assertion with the original testcase).
Assignee | ||
Comment 3•18 years ago
|
||
So, this look similar to bug 329762. Somewhere, some view is probably not getting reparented correctly. Now to find out where...
Assignee: nobody → uriber
Assignee | ||
Comment 4•18 years ago
|
||
This re-parents the views on the new frame(s), if we decide it's going to have a different parent. As far as I can tell, it fixes the bug.
Alternatively (and perhaps better), we might be able to create the new frame with the correct parent to begin with. This means pushing the logic for finding the last continuation of the :before pseudo-element upwards, to before where we create the new frame. It kind of scares me, so I'll try to do it only if it is really considered a better approach.
Attachment #232716 -
Flags: review?(roc)
Comment on attachment 232716 [details] [diff] [review]
one option
Let's do this for now, it's more branch-friendly.
Attachment #232716 -
Flags: superreview+
Attachment #232716 -
Flags: review?(roc)
Attachment #232716 -
Flags: review+
Assignee | ||
Comment 6•18 years ago
|
||
Checked in, but mentioned the wrong bug number (bug 343540) in the checkin comment.
Checking in layout/base/nsCSSFrameConstructor.cpp;
/cvsroot/mozilla/layout/base/nsCSSFrameConstructor.cpp,v <-- nsCSSFrameConstructor.cpp
new revision: 1.1248; previous revision: 1.1247
done
Status: NEW → RESOLVED
Closed: 18 years ago
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha
Updated•18 years ago
|
Whiteboard: post 1.8-branch
Updated•18 years ago
|
Group: security
Flags: wanted1.8.1.x-
Updated•13 years ago
|
Crash Signature: [@ nsIView::Destroy]
You need to log in
before you can comment on or make changes to this bug.
Description
•