Open Bug 1627015 Opened 4 years ago Updated 4 years ago

Potential assertion failure/broken behaviour in specific edge case page construction

Categories

(Core :: Panning and Zooming, defect, P3)

defect

Tracking

()

Tracking Status
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- fix-optional
firefox78 --- fix-optional

People

(Reporter: kats, Unassigned)

References

Details

(Whiteboard: [apz:pos_sticky:5:M])

I debugged the crashtest failure at https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&selectedJob=295951251&revision=26613321f9e401aea4bbc86fae3d78bd8f99ed73 which has a mostly-complete patch for bug 1610731.

The crashtest failure can be avoided, but it points at an underlying problem in the way we create the WebRenderScrollLayerData instances. Consider the following simplified display list, where there is a sticky item inside a transform inside a scrollframe (layout/reftests/async-scrolling/sticky-inside-transform-1.html)

- some nsDisplayItem with asr (<a>)
- nsDisplayCompositorHitTestInfo with asr(<b>, <a>)
- nsDisplayTransform with asr(<b>, <a>) and non-empty transform
  - nsDisplayStickyPosition with asr(<b>, <a>)

The hit-test item will generate a WRSLD by virtue of having a different ASR than the preceding item. The transform item will be deferred, and then the sticky item may generate a WRSLD. When that sticky item generates its WRSLD, it will have the same scroll metadata (and therefore is positioned in the APZ tree similarly to) the WRSLD from the hit test info item. However, it will also have an ancestor transform (which comes from the deferred transform item), while the hit-test info one does not. This eventually causes this assertion to fail.

I think the proper solution here is to force the deferred transform to generate its own WRSLD item, similar to what we do here. But the condition to do so is a little unclear - I guess we want to do it if we've already generated a WRSLD from an item with the same ASRs but that is outside the transform. Tracking this might be non-trivial, which is why I'm spinning this off into another bug.

Also before I forget: after bug 1610731 lands, I think that the assertion might be reproducible on Android debug if layout/reftests/async-scrolling/sticky-inside-transform-1.html is run with the dynamic toolbar test prefs: test-pref(apz.fixed-margin-override.enabled,true) test-pref(apz.fixed-margin-override.bottom,50). There's a chance it might not be if we end up going through some condition that makes nsDisplayStickyPosition::UpdateScrollData return false instead of true. I haven't actually tried it.

Whiteboard: [apz:pos_sticky:5:M]
You need to log in before you can comment on or make changes to this bug.