Closed Bug 291902 Opened 20 years ago Closed 19 years ago

Crash [@ nsCSSFrameConstructor::WipeContainingBlock] with path:hover {display:block}

Categories

(Core :: SVG, defect, P2)

defect

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)

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).
Attached image Testcase (deleted) —
Attached file Crash log (deleted) —
The testcase makes my self-compiled build (svg-enabled) from 050423 crash on Mac OS 10.3.9.
Also crashes with path:hover{position:absolute;}
Summary: Crash with path:hover {display:block} → Crash [@ nsCSSFrameConstructor::WipeContainingBlock] with path:hover {display:block}
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...
Blocks: 296086
I've hit this crash a few times while playing with bug 306663. I'd appreciate a fix for this crash.
Blocks: stirdom
Blocks: 310933
Blocks: 285964
Attached patch Proposed patch (obsolete) (deleted) — Splinter Review
This should fix it. Also fixes the non-tracking bugs this blocks.
Attachment #198533 - Flags: superreview?(dbaron)
Attachment #198533 - Flags: review?(dbaron)
Attached patch Slightly better (obsolete) (deleted) — Splinter Review
Attachment #198533 - Attachment is obsolete: true
Attachment #198533 - Flags: superreview?(dbaron)
Attachment #198533 - Flags: review?(dbaron)
Attachment #198876 - Flags: superreview?(dbaron)
Attachment #198876 - Flags: review?(dbaron)
Attached file testcase2 (deleted) —
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 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+
Attached patch Updated to comments (deleted) — Splinter Review
Attachment #198876 - Attachment is obsolete: true
Assignee: general → bzbarsky
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
Er... actually fixed now. checkin didn't go through the first time. :(
Blocks: 294445
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
Blocks: 329044
Flags: blocking1.8.0.3?
Comment on attachment 199601 [details] [diff] [review] Updated to comments a=timr based on conversation with dvedtz
Attachment #199601 - Flags: approval1.8.0.2+
*** Bug 329044 has been marked as a duplicate of this bug. ***
crash fix checked into the 1.8 and 1.8.0 branches
Flags: blocking1.8.0.3? → blocking1.8.0.2+
Whiteboard: [rft-dl]
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.
Blocks: 144004
Crash Signature: [@ nsCSSFrameConstructor::WipeContainingBlock]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: