Crash in PaintRowGroupBackgroundByColIdx

VERIFIED FIXED in Firefox 58

Status

()

Core
Layout: Tables
--
critical
VERIFIED FIXED
a month ago
a month ago

People

(Reporter: calixte, Assigned: bz)

Tracking

(Blocks: 1 bug, {crash, regression})

58 Branch
mozilla58
Unspecified
All
crash, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox56 unaffected, firefox57 unaffected, firefox58 verified)

Details

(Whiteboard: [clouseau], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

a month ago
This bug was filed from the Socorro interface and is 
report bp-67e3df6d-5102-4a5b-b924-711220171018.
=============================================================

There are 14 crashes in nightly 58 with buildid 20171018100140. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1409154.
The crash reason is always "MOZ_RELEASE_ASSERT(!aColIdx.IsEmpty()) (Must be painting backgrounds for something)".

[1] https://hg.mozilla.org/mozilla-central/rev?node=761b8e0abad4051975009857f1aac6e0b002ab62
Flags: needinfo?(bzbarsky)
Yeah, ok.  That's why I added the release assert; I was afraid it might fail.

We don't seem to have any URLs associated with this, right?
Assignee: nobody → bzbarsky
I guess one way this could happen is like so:

  <table>
    <tr><td></td></tr>
  </table>
  <script>
    document.body.offsetWidth;
    document.querySelector("td").remove();
  </script>

and then someone doing hit-testing (as in the observed stacks) before layout happens and the now-empty anonymous colgroup gets resized to be 0-width.  I haven't managed to reproduce this situation so far, but I don't see anything that would prevent it.
Flags: needinfo?(bzbarsky)
Created attachment 8919837 [details] [diff] [review]
Guard against empty column groups when building a display list for a table

MozReview-Commit-ID: E31B1wqNbSu
Attachment #8919837 - Flags: review?(mats)
Comment on attachment 8919837 [details] [diff] [review]
Guard against empty column groups when building a display list for a table

r=mats
Attachment #8919837 - Flags: review?(mats) → review+
Not sure if this is useful, while there's already a r+ patch attached, but I have found a somewhat reliable way to reproduce this (it seems to be a race).

1) Open https://groups.google.com/a/mozilla.com/forum/#!overview
2) Select "browse all"
3) Scroll down and see how it lists more. 
4) Enter something in the search bar on top to look for groups containing something
I think the loading and fetching on scrolling needs to race with the search results.

Let me know if there's anything else I can do to help.
Just saw this in Gmail switching from my inbox to a filter:

https://crash-stats.mozilla.com/report/index/cdb32889-f9fb-4ab2-aae4-f464d0171019
I haven't managed to reproduce this, much less write a test...  Going to just check in the patch.

Comment 8

a month ago
Pushed by bzbarsky@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e0e10152c2de
Guard against empty column groups when building a display list for a table.  r=mats
https://hg.mozilla.org/mozilla-central/rev/e0e10152c2de
Status: NEW → RESOLVED
Last Resolved: a month ago
status-firefox58: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
(Reporter)

Comment 10

a month ago
No more crash after buildid 20171020100426.
Status: RESOLVED → VERIFIED
status-firefox58: fixed → verified
You need to log in before you can comment on or make changes to this bug.