Found via bughunter and reproduced on a windows 7 debug build as well as on a nightly opt build based on m-c tip also on mac Steps to reproduce: --> Load https://prevoty.com/ ----> Crash
Created attachment 8749605 [details] bughunter stack and https://crash-stats.mozilla.com/report/index/ebefcb42-18e7-4ccf-a0a9-579652160506 for the opt crash
Summary: Crash in mozilla::gfx::Matrix4x4Typed<T> mozilla::gfx::Matrix4x4Typed<T>::operator*<T> const → Crash due to stack overflow in ComputeEffectiveTransformsForChildren
Maybe layout should avoid putting us in this situation?
Assignee: nobody → matt.woodrow
Created attachment 8750546 [details] [diff] [review] double-blend-container
Attachment #8750546 - Flags: review?(mstange)
Why is this necessary? What's happening here? Don't we still need different keys for different nsDisplayBlendMode items for the same frame?
The problem is that we build two nsDisplayBlendContainers for the same frame, and FrameLayerBuilder gets confused and builds a ContainerLayer with itself as its first child. We had mIndex to prevent this, but it was always zero, so didn't do anything. As far as I can tell we can only ever have two blend containers per frame (one for mix-blend-mode, and one for background-blend-mode), so switching to a boolean seems sufficient (and clearer). We can still build an arbitrary number of nsDisplayBlendModes, but those already use indexes correctly.
Oops, I got confused with nsDisplayBlendContainer vs nsDisplayBlendMode. Sounds good.
Comment on attachment 8750546 [details] [diff] [review] double-blend-container Review of attachment 8750546 [details] [diff] [review]: ----------------------------------------------------------------- thanks
Attachment #8750546 - Flags: review?(mstange) → review+
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox49: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
You need to log in before you can comment on or make changes to this bug.