Crash [@GetTablePartRank] with overflow: auto; display: table-row-group; and onmouseover style change

VERIFIED FIXED

Status

()

Core
Layout: Tables
--
critical
VERIFIED FIXED
12 years ago
7 years ago

People

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

Tracking

(4 keywords)

Trunk
x86
Windows XP
crash, regression, testcase, topcrash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(3 attachments)

(Reporter)

Description

12 years ago
See upcoming testcase, which crashes current trunk Mozilla build when hovering over the text.
Doesn't crash in 2006-04-17 build, crashes in 2006-04-18 build.

Talkback ID: TB17801522Y
GetTablePartRank   nsDisplayList::Sort   nsTableFrame::BuildDisplayList   nsIFrame::BuildDisplayListForChild  

Most likely a regression from bug 333481.
(Reporter)

Comment 1

12 years ago
Created attachment 219292 [details]
testcase

Comment 2

12 years ago
sound like the assumption that a rowgroup parent is a table is made, this is wrong for overflow frames there the parent is the scrollframe.

Comment 3

12 years ago
Me too - TB17809249E (and others this morning)
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060420 Minefield/3.0a1

Win2k platform - anyone try Linux?

Comment 4

12 years ago
TB17814175E
TB17813955W

Updated

12 years ago
Summary: Crash with overflow: auto; display: table-row-group; and onmouseover style change → Crash [@GetTablePartRank] with overflow: auto; display: table-row-group; and onmouseover style change

Comment 5

12 years ago
http://lxr.mozilla.org/seamonkey/source/layout/base/nsDisplayList.h#918

says:
918  * In some cases (e.g., clipping) we want to wrap a list but we don't have a
919  * particular underlying frame that is a stacking context root. In that case
920  * we allow the frame to be nsnull. Callers to GetUnderlyingFrame must
921  * detect and handle this case.

nsIAtom* type = aItem->GetUnderlyingFrame()->GetType(); 

isn't exactly complying with this requirement.

Comment 6

12 years ago
Created attachment 219414 [details] [diff] [review]
hack that fixed the crash and makes the rendeirng correct

Robert I have no idea:
- what we need to return if mFrame is 0
- whether we should hit the case at all (aka wallpaper)
- why we dont mention the cell frame here below (this might be the other regression)
Ugh.

My fix for bug 333481 won't fix the problem in the presence of a scrolling rowgroup. I think we should fix that, and this crash, by calling nsDisplayList::ExplodeAnonymousChildLists before we try to sort by table part rank.
Flags: blocking1.9a1?

Comment 8

12 years ago
Robert:
>I think we should fix that

Is that *we*,  you (hopefully) or me?

Comment 10

12 years ago
[@ GetTablePartRank] is the #18 topcrash on trunk.  Some comments mention real-world pages rather than this testcase.  Assuming a fix here will fix the crash and adding "topcrash" keyword.
Keywords: topcrash
Created attachment 219825 [details] [diff] [review]
fix

What I said ...
Assignee: nobody → roc
Status: NEW → ASSIGNED
Attachment #219825 - Flags: review?(bernd_mozilla)

Updated

12 years ago
Attachment #219825 - Flags: review?(bernd_mozilla) → review+

Comment 12

12 years ago
*** Bug 335613 has been marked as a duplicate of this bug. ***

Comment 13

12 years ago
> Some comments mention
> real-world pages rather than this testcase.

One is:
http://web.tampabay.rr.com/bmerkey/examples/nonscroll-table-header.html
checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Verified FIXED using 04-27-16 build of SeaMonkey trunk on Windows XP with both:

https://bugzilla.mozilla.org/attachment.cgi?id=219292&action=view
and
http://web.tampabay.rr.com/bmerkey/examples/nonscroll-table-header.html testcases.
Status: RESOLVED → VERIFIED
Flags: blocking1.9a1?
Crash Signature: [@GetTablePartRank]
You need to log in before you can comment on or make changes to this bug.