Closed Bug 919156 Opened 6 years ago Closed 6 years ago

Crash in mozilla::layers::Layer::CalculateScissorRect(nsIntRect const&, gfxMatrix const*) with position:sticky enabled


(Core :: Layout, defect, critical)

26 Branch
Windows 8
Not set



Tracking Status
firefox25 --- unaffected
firefox26 - affected
firefox27 - affected
firefox28 - affected


(Reporter: hexboris, Unassigned)



(Keywords: crash, reproducible)

Crash Data


(2 files)

187.85 KB, application/octet-stream
2.93 KB, text/html
Attached file
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:


Expected results:

No crash
Crash Signature: mozilla::layers::Layer::CalculateScissorRect(nsIntRect const&, gfxMatrix const*)
Severity: normal → critical
Ever confirmed: true
Keywords: crash, reproducible
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?
Flags: needinfo?(dbaron)
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.
Attached file crash scenario
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.
Flags: needinfo?(kairo)
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.
Flags: needinfo?(kairo)
=> 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.
Flags: needinfo?(sjw)
Seems fixed by 931460
Closed: 6 years ago
Flags: needinfo?(sjw)
Resolution: --- → WORKSFORME
(In reply to sjw from comment #14)
> Seems fixed by 931460

I don't think so.

Working range:

My guess goes to:
Robert O'Callahan — Bug 919144. Part 10: Fold nsDisplayFixedPosition into nsDisplayStickyPosition. r=mattwoodrow
Depends on: 919144
Flags: needinfo?(dbaron)
You need to log in before you can comment on or make changes to this bug.