Closed Bug 980223 Opened 11 years ago Closed 11 years ago

Emptying a tbody with a relatively positioned td crashes Firefox

Categories

(Core :: Layout: Tables, defect, P1)

x86
macOS
defect

Tracking

()

VERIFIED FIXED
mozilla30
Tracking Status
firefox30 - ---

People

(Reporter: robin, Assigned: seth)

References

Details

(4 keywords)

Crash Data

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release) Build ID: 20140305170806 Steps to reproduce: Booted today’s Nightly, which automatically started rendering our company jukebox. I don’t have a reduced testcase and the code isn’t public, but I can supply one if required. Hopefully it’s obvious from the crash signature and window. Actual results: Crash. Some signatures: https://crash-stats.mozilla.com/report/index/3b6207be-f652-4119-94e4-535822140306 https://crash-stats.mozilla.com/report/index/393e8d94-f31d-40c0-811e-4c90a2140306 Expected results: No boom. I definitely had a nightly from two days ago that wasn’t crashing, think I also was using yesterday’s without incident.
Severity: normal → critical
Component: Layout → Layout: Tables
Keywords: crash, regression
Priority: -- → P1
Ah yeah, that’ll be it (the central layout is a grid of upcoming tracks and the CSS has td { position: relative; }. I don’t have time at the moment but I can make a reduced testcase later if that’s needed?
Attached file Testcase
OK, so here’s a reduced testcase. If you empty a <tbody> that has a relatively positioned <td> in it Firefox crashes.
Summary: Reflow crash in today’s nightly → Emptying a tbody with a relatively positioned td crashes Firefox
bp-468d9aa7-6a60-4e9a-96ef-dc3142140306 Regression window Good: https://hg.mozilla.org/integration/mozilla-inbound/rev/c75ce018e5db Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140303193956 Crash: https://hg.mozilla.org/integration/mozilla-inbound/rev/11ab722b0bcb Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140303201657 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c75ce018e5db&tochange=11ab722b0bcb
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Emptying a tbody with a relatively positioned td crashes Firefox → Emptying a tbody with a relatively positioned td crashes Firefox [@ nsHTMLReflowState::nsHTMLReflowState(nsPresContext*, nsIFrame*, nsRenderingContext*, nsSize const&, unsigned int)]
Blocks: 980288
Crash Signature: [@ nsHTMLReflowState::nsHTMLReflowState(nsPresContext*, nsIFrame*, nsRenderingContext*, nsSize const&, unsigned int)]
Summary: Emptying a tbody with a relatively positioned td crashes Firefox [@ nsHTMLReflowState::nsHTMLReflowState(nsPresContext*, nsIFrame*, nsRenderingContext*, nsSize const&, unsigned int)] → Emptying a tbody with a relatively positioned td crashes Firefox
Blocks: 63895
Flags: in-testsuite?
Taking this.
Assignee: nobody → seth
Flags: needinfo?(seth)
(In reply to Robin Whittleton from comment #3) > OK, so here’s a reduced testcase. If you empty a <tbody> that has a > relatively positioned <td> in it Firefox crashes. Thanks Robin, that's super helpful!
I've fixed this problem, but since I backed out bug 63895, I decided to just update the patches there. We can consider this resolved by the backout.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
No longer blocks: 980288
(In reply to Seth Fowler [:seth] from comment #8) > I've fixed this problem, but since I backed out bug 63895, I decided to just > update the patches there. We can consider this resolved by the backout. I don't think this is fixed yet since its not landed on central yet... I'm hitting the same signature pretty frequently on current nightly.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Tracking this for now since its a regression and topcrash will re-evaluate when fixed.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Verified fix on 3/8 mac nightly, 30.0a1. My crash no longer appears after updating today. https://crash-stats.mozilla.com/report/index/1e00b804-f664-49a0-9fc5-7f10a2140308 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Firefox/30.0
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla30
Does this need a test for the crashing scenario, or are the tests from bug 63895 enough? Thanks!
Flags: needinfo?(seth)
(In reply to Mihaela Velimiroviciu [QA] (:mihaelav) from comment #13) > Does this need a test for the crashing scenario, or are the tests from bug > 63895 enough? > Thanks! Just had a look and I don't think that the tests from bug 63895 cover this. However, the tests from bug 35168 (which recently got backed out, but I'll try to land them again this week) should cover this. So I don't think we're going to need a separate test for this bug.
Flags: needinfo?(seth)
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: