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

VERIFIED FIXED in mozilla1.9alpha1

Status

()

Core
SVG
P2
critical
VERIFIED FIXED
13 years ago
11 years ago

People

(Reporter: Martijn Wargers (dead), Assigned: bz)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
mozilla1.9alpha1
crash, fixed1.8.1, testcase, verified1.8.0.2
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.0.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rft-dl], crash signature)

Attachments

(4 attachments, 2 obsolete attachments)

(Reporter)

Description

13 years ago
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

13 years ago
Created attachment 181849 [details]
Testcase

Comment 2

13 years ago
Created attachment 181897 [details]
Crash log

The testcase makes my self-compiled build (svg-enabled) from 050423 crash on
Mac OS 10.3.9.
(Reporter)

Comment 3

13 years ago
Also crashes with path:hover{position:absolute;}
(Reporter)

Updated

13 years ago
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...
(Reporter)

Updated

12 years ago
Blocks: 296086

Comment 5

12 years ago
I've hit this crash a few times while playing with bug 306663.  I'd appreciate a
fix for this crash.

Updated

12 years ago
Blocks: 306663
(Assignee)

Updated

12 years ago
Blocks: 310933
(Assignee)

Updated

12 years ago
Blocks: 285964
Created attachment 198533 [details] [diff] [review]
Proposed patch

This should fix it.  Also fixes the non-tracking bugs this blocks.
Attachment #198533 - Flags: superreview?(dbaron)
Attachment #198533 - Flags: review?(dbaron)
Created attachment 198876 [details] [diff] [review]
Slightly better
Attachment #198533 - Attachment is obsolete: true
(Assignee)

Updated

12 years ago
Attachment #198533 - Flags: superreview?(dbaron)
Attachment #198533 - Flags: review?(dbaron)
(Assignee)

Updated

12 years ago
Attachment #198876 - Flags: superreview?(dbaron)
Attachment #198876 - Flags: review?(dbaron)
(Reporter)

Comment 8

12 years ago
Created attachment 198937 [details]
testcase2

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+
Created attachment 199601 [details] [diff] [review]
Updated to comments
Attachment #198876 - Attachment is obsolete: true
(Assignee)

Updated

12 years ago
Assignee: general → bzbarsky
Fixed on trunk.
Status: NEW → RESOLVED
Last Resolved: 12 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.  :(
(Assignee)

Updated

12 years ago
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
(Assignee)

Updated

12 years ago
Blocks: 329044
Flags: blocking1.8.0.3?

Comment 14

12 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+
*** 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+
Keywords: fixed1.8.0.2, fixed1.8.1

Updated

12 years ago
Whiteboard: [rft-dl]

Comment 17

12 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
(Assignee)

Updated

11 years ago
Blocks: 144004
Crash Signature: [@ nsCSSFrameConstructor::WipeContainingBlock]
You need to log in before you can comment on or make changes to this bug.