2003843 - anchored elements can incorrectly be drawn with the transform of the anchor

Status: NEW

(Core :: Graphics: WebRender, defect)

Description

[Timothy Nikkel (:tnikkel)]

Attachment: anchortransform2.html

As a product of bug 1988032 anchored frames will get assigned the ASR of the anchor. This means they will have the same spatial node as the anchor in webrender. The result of this is that if the anchor is subject to a transform that the anchored frame is not then the anchored frame will get drawn with that transform (incorrectly).

My understanding is that the spec for transforms with anchor hasn't been written yet so in this case the anchored content will be anchored to the untransformed location of the anchor (ie it won't look like it is anchored), so sites are not likely to do this.

We can just not assign the ASR of the anchor is this situation, so that we render correctly but lose async scrolling. Doing this is actually tricky because we our want decision of which ASR to assign to be consistent (when done in different places), however determining if a transform affects in this way depends on both the anchor and the anchored content (two different anchored frames could be anchored to one anchor with only one of them being affected by a transform in this way), and anchors can chain making this a potential multistep process with different decisions at each anchor and whose decision depends on inputs to that decision that might be determined far away.

Comment 1

[Jonathan Watt [:jwatt]]

(In reply to Timothy Nikkel (:tnikkel) from comment #0)

My understanding is that the spec for transforms with anchor hasn't been written yet so in this case the anchored content will be anchored to the untransformed location of the anchor (ie it won't look like it is anchored), so sites are not likely to do this.

Google's intent to ship just linked to the section of the archor spec called The Anchor Box FWIW.

Comment 2

[David Shin[:dshin]]

The spec says the scroll is handled "specially" to provide an escape hatch for scrolling. If we ignore that for a moment, given the spec text for the anchor box, I expect the positioned element to be untransformed but also to stick to the right side of axis-aligned rect of anchor. Chrome doesn't do the latter, so it just scrolls up and down, looking rather disjointed.

So I don't think this is a critical issue, at least - Transform + scroll compensation feels... rare. Spec issue in linked bug doesn't seem to have such case, either. One case brought up is a sliding side panel, but in that case I think this unintended transform doesn't seem that bad.

... That said, I guess one way this can go wrong is if the positioned element happens to be scroll compensated, and we implement bug 1993692, we may potentially double-apply the effect of transform (Once by implementing bug 1993692, another by ASR assignment).

Comment 3

[Timothy Nikkel (:tnikkel)]

(In reply to David Shin[:dshin] from comment #2)

The spec says the scroll is handled "specially" to provide an escape hatch for scrolling. If we ignore that for a moment, given the spec text for the anchor box, I expect the positioned element to be untransformed but also to stick to the right side of axis-aligned rect of anchor. Chrome doesn't do the latter, so it just scrolls up and down, looking rather disjointed.

Presumably with their intent to ship from above Chrome's behaviour will change soon?

So I don't think this is a critical issue, at least - Transform + scroll compensation feels... rare. Spec issue in linked bug doesn't seem to have such case, either. One case brought up is a sliding side panel, but in that case I think this unintended transform doesn't seem that bad.

... That said, I guess one way this can go wrong is if the positioned element happens to be scroll compensated, and we implement bug 1993692, we may potentially double-apply the effect of transform (Once by implementing bug 1993692, another by ASR assignment).

Yeah, we'll likely have to do something about that when we implement bug 1993692.