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

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect)

Description

[Martijn Wargers (dead)]

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.

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

Comment 2

[Bernd]

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

[james davis]

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

[Mike Pesce (:By-Tor)]

TB17814175E
TB17813955W

Comment 5

[Bernd]

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

[Bernd]

Attachment: 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)

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 8

[Bernd]

Robert:
>I think we should fix that

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

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'll do it.

Comment 10

[Jesse Ruderman]

[@ 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.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

What I said ...

Comment 12

[Gérard Talbot]

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

Comment 13

[Gérard Talbot]

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

One is:
http://web.tampabay.rr.com/bmerkey/examples/nonscroll-table-header.html

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in

Comment 15

[Stephen Donner [:stephend] Not actively reading bugmail]

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.