Some display items might be getting a bogus spatial id

RESOLVED FIXED in Firefox 68

Status

()

enhancement
RESOLVED FIXED
3 months ago
3 months ago

People

(Reporter: kats, Assigned: kats)

Tracking

unspecified
mozilla68
Points:
---

Firefox Tracking Flags

(firefox68 fixed)

Details

Attachments

(1 attachment)

Spinoff from https://bugzilla.mozilla.org/show_bug.cgi?id=1538711#c6

While investigating bug 1538711 I noticed that a couple of display items inside the RDM'd content page had what appeared to be a wrong spatial id. This happened because the ClipManager took the early-exit codepath for those items and just returned the space and clip chain at the top of the stack which had been pushed in BeginList but not really populated. The default spatial id in this case was "0", being set here.

A spatial id of "0" on the WR side refers to the ROOT_REFERENCE_FRAME_SPATIAL_ID but I don't think we ever legitimately use it on the C++ side (see for example this comment). So I think what we really want to be setting this to is the root scroll id.

I did a try push with that change and it seemed to make no difference, but I think this is slightly more correct.

A spatial id of 0 refers to the root reference frame on the WR side, but
we shouldn't be using that on the Gecko side at all. Due to the
early-exit codepath in ClipManager we were actually sending some display
items with this spatial id over to WebRender. Although this doesn't
appear to cause any user-visible problems it seems wrong and can confuse
debugging other issues.

Comment 2

3 months ago
Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/79142ba66f4f
Initialize mScrollId to the root scroll id. r=kvark

Comment 3

3 months ago
bugherder
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.