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)
Tracking
()
VERIFIED
FIXED
mozilla30
Tracking | Status | |
---|---|---|
firefox30 | - | --- |
People
(Reporter: robin, Assigned: seth)
References
Details
(4 keywords)
Crash Data
Attachments
(1 file)
290 bytes,
text/html
|
Details |
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.
Comment 1•11 years ago
|
||
Severity: normal → critical
Component: Layout → Layout: Tables
Keywords: crash,
regression
Priority: -- → P1
Reporter | ||
Comment 2•11 years ago
|
||
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?
Reporter | ||
Comment 3•11 years ago
|
||
OK, so here’s a reduced testcase. If you empty a <tbody> that has a relatively positioned <td> in it Firefox crashes.
Reporter | ||
Updated•11 years ago
|
Summary: Reflow crash in today’s nightly → Emptying a tbody with a relatively positioned td crashes Firefox
Comment 4•11 years ago
|
||
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
Updated•11 years ago
|
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)]
Updated•11 years ago
|
Keywords: topcrash-mac,
topcrash-win
Updated•11 years ago
|
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
Updated•11 years ago
|
tracking-firefox30:
--- → ?
Updated•11 years ago
|
Flags: in-testsuite?
Flags: needinfo?(seth)
Assignee | ||
Comment 7•11 years ago
|
||
(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!
Assignee | ||
Comment 8•11 years ago
|
||
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
Updated•11 years ago
|
Comment 9•11 years ago
|
||
(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 → ---
Updated•11 years ago
|
Comment 10•11 years ago
|
||
Tracking this for now since its a regression and topcrash will re-evaluate when fixed.
Updated•11 years ago
|
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Comment 12•11 years ago
|
||
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
Updated•11 years ago
|
Target Milestone: --- → mozilla30
Comment 13•10 years ago
|
||
Does this need a test for the crashing scenario, or are the tests from bug 63895 enough?
Thanks!
Flags: needinfo?(seth)
Assignee | ||
Comment 14•10 years ago
|
||
(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)
Comment 15•8 years ago
|
||
Pushed by mpalmgren@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/db7b7aab1524
Crashtest.
Updated•8 years ago
|
Flags: in-testsuite? → in-testsuite+
Comment 16•8 years ago
|
||
bugherder |
You need to log in
before you can comment on or make changes to this bug.
Description
•