Closed
Bug 291902
Opened 20 years ago
Closed 19 years ago
Crash [@ nsCSSFrameConstructor::WipeContainingBlock] with path:hover {display:block}
Categories
(Core :: SVG, defect, P2)
Core
SVG
Tracking
()
VERIFIED
FIXED
mozilla1.9alpha1
People
(Reporter: martijn.martijn, Assigned: bzbarsky)
References
Details
(4 keywords, Whiteboard: [rft-dl])
Crash Data
Attachments
(4 files, 2 obsolete files)
(deleted),
image/svg+xml
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
application/vnd.mozilla.xul+xml
|
Details | |
(deleted),
patch
|
timr
:
approval1.8.0.2+
|
Details | Diff | Splinter Review |
I just tried a win32 2005-03-24 trunk build with SVG enabled.
The testcase that I'll attach crashes that build for me when hovering over the
path element (the ellipse).
Reporter | ||
Comment 1•20 years ago
|
||
Comment 2•20 years ago
|
||
The testcase makes my self-compiled build (svg-enabled) from 050423 crash on
Mac OS 10.3.9.
Reporter | ||
Comment 3•20 years ago
|
||
Also crashes with path:hover{position:absolute;}
Reporter | ||
Updated•20 years ago
|
Summary: Crash with path:hover {display:block} → Crash [@ nsCSSFrameConstructor::WipeContainingBlock] with path:hover {display:block}
Assignee | ||
Comment 4•20 years ago
|
||
So the basic problem is that we end up with a block-inside-inline, try to
reframe the containing block, don't find one, and crash.
I suppose we could bail out of reframing the containing block if there is no
containing block, or just fall back on reconstructing the entire document
hierarchy.... Or we could introduce more svg-specific knowledge into the frame
constructor...
Comment 5•19 years ago
|
||
I've hit this crash a few times while playing with bug 306663. I'd appreciate a
fix for this crash.
Assignee | ||
Comment 6•19 years ago
|
||
This should fix it. Also fixes the non-tracking bugs this blocks.
Attachment #198533 -
Flags: superreview?(dbaron)
Attachment #198533 -
Flags: review?(dbaron)
Assignee | ||
Comment 7•19 years ago
|
||
Attachment #198533 -
Attachment is obsolete: true
Assignee | ||
Updated•19 years ago
|
Attachment #198533 -
Flags: superreview?(dbaron)
Attachment #198533 -
Flags: review?(dbaron)
Assignee | ||
Updated•19 years ago
|
Attachment #198876 -
Flags: superreview?(dbaron)
Attachment #198876 -
Flags: review?(dbaron)
Reporter | ||
Comment 8•19 years ago
|
||
This testcase crashes with the same backtrace, so I guess this too will be
fixed with this patch. (otherwise I'll file a new bug on it)
Comment 9•19 years ago
|
||
Comment on attachment 198876 [details] [diff] [review]
Slightly better
> if (parentContainer) {
> ReinsertContent(parentContainer, blockContent);
> }
> else {
>- NS_ERROR("uh oh. the block we need to reframe has no parent!");
>+ ReconstructDocElementHierarchy();
> }
Check blockContent->IsInDoc() before doing something that drastic, please?
Attachment #198876 -
Flags: superreview?(dbaron)
Attachment #198876 -
Flags: superreview+
Attachment #198876 -
Flags: review?(dbaron)
Attachment #198876 -
Flags: review+
Assignee | ||
Comment 10•19 years ago
|
||
Attachment #198876 -
Attachment is obsolete: true
Assignee | ||
Updated•19 years ago
|
Assignee: general → bzbarsky
Assignee | ||
Comment 11•19 years ago
|
||
Fixed on trunk.
Status: NEW → RESOLVED
Closed: 19 years ago
OS: Windows XP → All
Priority: -- → P2
Hardware: PC → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha
Assignee | ||
Comment 12•19 years ago
|
||
Er... actually fixed now. checkin didn't go through the first time. :(
Verified FIXED using both testcases on SeaMonkey 1.1a;Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051020 SeaMonkey/1.1a
Status: RESOLVED → VERIFIED
Updated•19 years ago
|
Flags: blocking1.8.0.3?
Comment 14•19 years ago
|
||
Comment on attachment 199601 [details] [diff] [review]
Updated to comments
a=timr based on conversation with dvedtz
Attachment #199601 -
Flags: approval1.8.0.2+
Comment 15•19 years ago
|
||
*** Bug 329044 has been marked as a duplicate of this bug. ***
Comment 16•19 years ago
|
||
crash fix checked into the 1.8 and 1.8.0 branches
Flags: blocking1.8.0.3? → blocking1.8.0.2+
Keywords: fixed1.8.0.2,
fixed1.8.1
Updated•19 years ago
|
Whiteboard: [rft-dl]
Comment 17•19 years ago
|
||
v.fixed on 1.8.0 branch with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060307 Firefox/1.5.0.2, no crash with either testcase.
Keywords: fixed1.8.0.2 → verified1.8.0.2
Updated•13 years ago
|
Crash Signature: [@ nsCSSFrameConstructor::WipeContainingBlock]
You need to log in
before you can comment on or make changes to this bug.
Description
•