The default bug view has changed. See this FAQ.

Crash involving ::-moz-table-row-group, overflow, position, and opacity [@ nsIView::GetOffsetTo]

RESOLVED FIXED

Status

()

Core
Layout: Tables
--
critical
RESOLVED FIXED
11 years ago
6 years ago

People

(Reporter: Jesse Ruderman, Assigned: Bernd)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
PowerPC
Mac OS X
crash, testcase, verified1.8.0.5, verified1.8.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.0.5 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical], crash signature)

Attachments

(5 attachments)

(Reporter)

Description

11 years ago
[sg:critical] because before I reduced the testcase, I got crashes with random addresses on top.  The only reduced testcases I managed to make were for nondeterministic null dereferences, so I will retest with the original file once this is fixed.

Stack signatures (functions on top of the stack) included:

[@ nsIView::GetOffsetTo] 
[@ nsCSSFrameConstructor::BeginBuildingScrollFrame] -- with random at top 
[@ nsCSSFrameConstructor::ContentInserted] 
[@ nsHTMLContainerFrame::CreateViewForFrame] 
[@ IncrementalReflow::AddCommand] 
[@ nsHTMLReflowState::InitConstraints]
(Reporter)

Comment 1

11 years ago
Created attachment 216197 [details]
reduced testcase for crash [@ nsIView::GetOffsetTo] 

Usually crashes after about 10 reloads.
(Reporter)

Updated

11 years ago
Whiteboard: [sg:critical]
(Assignee)

Comment 2

11 years ago
Created attachment 216414 [details]
reduced tectase that triggers assertion

###!!! ASSERTION: unexpected second call to SetInitialChildList: 'Not Reached',
file d:/moz_src/mozilla/layout/generic/nsContainerFrame.cpp, line 108

This happens on the scroll frame around the rowgroup which is a abs. containing block.
(Reporter)

Updated

11 years ago
Blocks: 331889
So what's GetAbsoluteContainingBlock returning here, and why?
Depends on: 330909
Flags: blocking1.9a1?
(Assignee)

Comment 4

11 years ago
Created attachment 219177 [details]
testcase without abs.pos. which triggers the assert

rowgroup pseudos are the parent frames at pseudoFrames.mRowGroup.mFrame. If we build however a scrollframe for the rowgroup, we have the scrollframe there and then we put the row on the childlist of the.... scrollframe allready occupied by the rowgroupframe. (The typical case of: NOBODY expects the Spanish Inquisition!)
(Assignee)

Updated

11 years ago
No longer depends on: 330909
(Assignee)

Comment 5

11 years ago
Created attachment 219269 [details] [diff] [review]
patch

This code is wrong since it has been written, the typical effect is that we loose the rowframe and all its children. Then its only a question what you stuffed inside this row to determine where we crash, abs. pos with opacity, seems nice, the abs.pos animated gif should work too. I guess we need to get this, once it has baked, back to branches.
Attachment #219269 - Flags: superreview?(bzbarsky)
Attachment #219269 - Flags: review?(bzbarsky)
Attachment #219269 - Flags: superreview?(bzbarsky)
Attachment #219269 - Flags: superreview+
Attachment #219269 - Flags: review?(bzbarsky)
Attachment #219269 - Flags: review+
(Assignee)

Comment 6

11 years ago
fix checked in, open for some stress tests by Jesse 
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Assignee)

Updated

11 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Updated

11 years ago
Assignee: nobody → bernd_mozilla
Status: REOPENED → NEW
(Assignee)

Updated

11 years ago
Status: NEW → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED
(Reporter)

Updated

11 years ago
Depends on: 336291
(Reporter)

Updated

11 years ago
Flags: blocking1.8.0.5?
Flags: blocking1.8.0.5? → blocking1.8.0.5+
(Assignee)

Updated

11 years ago
Attachment #219269 - Flags: approval-branch-1.8.1?(roc)
Attachment #219269 - Flags: approval-branch-1.8.1?(roc) → approval-branch-1.8.1+
Comment on attachment 219269 [details] [diff] [review]
patch

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #219269 - Flags: approval1.8.0.5+
(Assignee)

Comment 8

11 years ago
fix checked in into branches
Keywords: fixed1.8.0.5, fixed1.8.1

Comment 9

11 years ago
v.fixed on 1.8.0 branch with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US;
rv:1.8.0.5) Gecko/20060626 Firefox/1.5.0.5, no crash with testcase.
Keywords: fixed1.8.0.5 → verified1.8.0.5
(In reply to comment #0)
> [sg:critical] because before I reduced the testcase, I got crashes with random
> addresses on top.  The only reduced testcases I managed to make were for
> nondeterministic null dereferences, so I will retest with the original file
> once this is fixed.

Jesse: Do you still have the original testcase, and if so did this really fix it?

asac: I don't think anyone tested this on the 1.7 branch.
(Reporter)

Comment 11

11 years ago
I think I tested the original testcase (and various intermediate testcases) shortly after this was fixed and didn't hit any more crashes.  I think the more recent fix for bug 331883 affects how Gecko thinks about this testcase.

Comment 12

11 years ago
Created attachment 232739 [details] [diff] [review]
1.0.x patch

Comment 13

11 years ago
https://bugzilla.mozilla.org/attachment.cgi?id=216197
ff2b2 no crash windows, linux, macppc

https://bugzilla.mozilla.org/attachment.cgi?id=216414&action=view
ff2b2 windows, linux, macppc no crash; windows, linux no assert

https://bugzilla.mozilla.org/attachment.cgi?id=219177
ff2b2 windows, linux, macppc; windows, linux no assert
Keywords: fixed1.8.1 → verified1.8.1

Comment 14

11 years ago
verified fixed 1.8
Flags: blocking1.9a1?
Group: security
Flags: in-testsuite?
(Reporter)

Comment 15

9 years ago
Crashtests checked in.
Flags: in-testsuite? → in-testsuite+
(Reporter)

Comment 16

9 years ago
The crashtests trigger CSS errors because bug 331883 has been fixed -- web pages cannot reference these internal pseudo-elements at all.
Crash Signature: [@ nsIView::GetOffsetTo]
You need to log in before you can comment on or make changes to this bug.