Closed Bug 919156 Opened 6 years ago Closed 6 years ago
Crash in mozilla::layers::Layer::Calculate
Scissor Rect(ns Int Rect const&, gfx Matrix const*) with position:sticky enabled
User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release) Build ID: 20130921004001 Steps to reproduce: 1. Open Aurora and enable layout.css.sticky.enabled 2. Open attached page 3. Scroll list on the right 4. Crash 5. No Profit Actual results: Crash Expected results: No crash
Crash Signature: mozilla::layers::Layer::CalculateScissorRect(nsIntRect const&, gfxMatrix const*)
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Position sticky crashes Firefox Aurora 26 → Crash in mozilla::layers::Layer::CalculateScissorRect(nsIntRect const&, gfxMatrix const*) with position:sticky enabled
Crash Signature: mozilla::layers::Layer::CalculateScissorRect(nsIntRect const&, gfxMatrix const*) → [@ mozilla::layers::Layer::CalculateScissorRect(nsIntRect const&, gfxMatrix const*) ]
Dbaron - who will be taking on these bugs now that Corey's internship is over?
Sorry, I was supposed to help figure that out. This bug in particular looks like it would need someone working on D3D10 to debug it further. (I recall that I looked at the method in question and no potential null dereferences or such jumped out at me.)
It seems that Firefox crashs because the sticky element is in a fixed element. If you remove L87 (position: fixed) in "Edit - Loudworks Casting.htm" from attachment 808156 [details] it works.
So it's possible this is related somehow to bug 919434, though this one doesn't look like a stack overflow.
I created another crash page without any content except the crash scenario. 1. enable layout.css.sticky.enabled 2. Scroll through text 3. Reload Page 4. Crash
position:sticky stayed back on Aurora so it should not be affecting FF26 anymore, untracking and ni? on KaiRo to confirm this is true in stats.
I can't tell from data, as this is an extremely low-volume crash and actually most of the instances of this signature I'm seeing are in data are from releases like 23, 24, and 25, so it looks like position:sticky might just be triggering a crash that has been around for a while. In any case it looks like low volume on all channels.
=> FF28 affected Is it normal that it doesn't crash if you view it in an iframe?
This continues to be extremely low volume, I don't recommend tracking unless we intend to have sticky enabled through release on 28.
Untracking, if this becomes a topcrasher can renom but otherwise just put an uplift nom on the patch when ready (and when sticky is truly shipping).
Should the test case in comment 7 trigger the crash every time or is this intermittent? I can't seem to trigger it on a nightly from around Dec 2.
Seems fixed by 931460
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
(In reply to sjw from comment #14) > Seems fixed by 931460 I don't think so. Working range: bad=2013-11-18 good=2013-11-19 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=beddd6d4bcdf&tochange=ba9ecdea3a90 My guess goes to: Robert O'Callahan — Bug 919144. Part 10: Fold nsDisplayFixedPosition into nsDisplayStickyPosition. r=mattwoodrow
Depends on: 919144
You need to log in before you can comment on or make changes to this bug.