Intent to Ship: Change scroll position values of elements in non-default writing modes.

[cathie chen]

Contact emails

cathi...@igalia.com, fw...@igalia.com

Explainer

None, scrolling-related JS API have been implemented before the intent-to-* process was in place and discussions happened in the past at the CSS WG:

https://github.com/w3c/csswg-drafts/issues/1354 (non-default CSS direction)

https://github.com/w3c/csswg-drafts/issues/2704 (non-default CSS writing-mode)

Spec

https://drafts.csswg.org/cssom-view/#scrolling-area-origin 

https://drafts.csswg.org/cssom-view/#scroll-an-element 

Summary

Per the CSSOM View specification, the horizontal (respectively vertical) scroll position of an element increases rightwards respectively downward), is ≥ 0 if the overflow direction is rightward (respectively downward) and ≤ 0 if the overflow direction is leftward (respectively upward).

In Blink, the scroll position values of an element evolve according to the spec but they are always nonnegative, which is wrong when the overflow direction is leftward or upward.

This is a proposal to change the behavior to match the specification, so that scroll positions are more consistent with the values used for the document's viewport and are interoperable with Gecko and WebKit's behavior.

Link to “Intent to Implement” blink-dev discussion

None, scrolling-related JS API have been implemented before the intent-to-* process was in place.

Link to Origin Trial feedback summary

None, scrolling-related JS API have been implemented before the intent-to-* process was in place.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

https://people.igalia.com/fwang/scrollLeft-scrollTop.html 

Debuggability

DevTools can access scrolling positions.

Risks

Interoperability and Compatibility

Edge: No signals

Firefox: Shipped

Safari: Shipped

Web / Framework developers: Various requests for interoperability.

This change will make the behavior interoperable in all browsers. A request to align Gecko's behavior with Blink's one was resolved as invalid. Apple changed legacy WebKit's behavior to match the spec and indicated it is the correct one. Microsoft didn't formulate any opinion on their bug tracker. Discussions on Blink's issue 721759 seem to lean toward fixing that issue by aligning on the spec.

Regarding compatibility, the risk is absent for elements using horizontal-tb + ltr writing mode or when developers rely on relative scroll positions. There is a risk to break websites that rely on absolute scroll positions in other writing modes but such websites will likely have feature-detection to workaround current interoperability issues.

Links:

https://bugs.chromium.org/p/chromium/issues/detail?id=721759 

https://bugs.webkit.org/show_bug.cgi?id=172028 

https://bugzilla.mozilla.org/show_bug.cgi?id=1364451 

https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/11996758/ 

https://github.com/w3c/csswg-drafts/issues/1354 

https://github.com/w3c/csswg-drafts/issues/2704 

Ergonomics

Does not apply, this is not a new feature but a behavior change (shifting scroll positions).

Activation

Does not apply, this is not a new feature but a behavior change (shifting scroll positions).

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes: https://wpt.fyi/results/css/cssom-view/scrollLeftTop.html 

Note that this interoperability issue is reflected inside WPT tests. Some of these tests assume Blink's behavior (e.g. https://wpt.fyi/results/css/css-position/position-sticky-writing-modes.html ), some of them assume the spec's behavior (e.g. https://wpt.fyi/results/css/css-scroll-snap/snap-inline-block.html ) while others try to deal with inconsistent behaviors (e.g. https://wpt.fyi/results/css/cssom-view/scrollIntoView-vertical-rl-writing-mode.html ).

Entry on the feature dashboard

Does not apply, this is not a new feature but a behavior change (shifting scroll positions).

[Majid Valipour]

This is great!

It is definitely good to see more interop in this area. I am a bit selfish as it makes writing scroll related WPT tests easier.

Also as you pointed out, our old behavior was inconsistent between root scroller and inner scroller which this is going to fix.

I assume you are landing the code for this as well so this is probably more accurately intent to implement and ship.

If I am not mistaken the patch you are planning to land is https://chromium-review.googlesource.com/c/chromium/src/+/1700001.

> There is a risk to break websites that rely on absolute scroll positions in other writing modes but such websites will likely have feature-detection to workaround current interoperability issues.

Do you have an example of websites that do this correctly? what is the current best practice in the real world usage?

>  Note that this interoperability issue is reflected inside WPT tests. Some of these tests assume Blink's behavior (e.g. https://wpt.fyi/results/css/css-position/position-sticky-writing-modes.html ), some of them assume the spec's behavior (e.g. https://wpt.fyi/results/css/css-scroll-snap/snap-inline-block.html ) while others try to deal with inconsistent behaviors (e.g. https://wpt.fyi/results/css/cssom-view/scrollIntoView-vertical-rl-writing-mode.html ).

Do you plan to also remove workaround in existing tests or fix those that assume Blink's incorrect behavior?

This can be a follow up. But I also think it is fair to ask various owners to clean up their tests afterwards. It should be sufficient to file bugs against them.

Thanks

Majid

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a4d3e136-5fea-4d4d-9b3c-18a7377ff2e2%40chromium.org.

[Frédéric Wang]

On 23/07/2019 18:34, Majid Valipour wrote:

I assume you are landing the code for this as well so this is probably more accurately intent to implement and ship.

If I am not mistaken the patch you are planning to land is https://chromium-review.googlesource.com/c/chromium/src/+/1700001.

Correct.

> There is a risk to break websites that rely on absolute scroll positions in other writing modes but such websites will likely have feature-detection to workaround current interoperability issues.

Do you have an example of websites that do this correctly? what is the current best practice in the real world usage?

Detecting the wrong behavior is easy: Just check the sign of a scroll position in a rtl scroller at a non-initial position. We don't really have data but there is an old JS query scroll type detector here: https://github.com/othree/jquery.rtl-scroll-type. For example, it is mentioned here: https://stackoverflow.com/questions/24276619/better-way-to-get-the-viewport-of-a-scrollable-div-in-rtl-mode/24394376#24394376 

It's not clear whether Chromium can easily measure wrong usage in order to collect more metrics (e.g. setting a position outside the accepted range is probably common in order to scroll content to the scroll limits without explicitely calculated them).

Maybe as it was suggested on the bug, the feature should be developed under a flag in order to be safer?

>  Note that this interoperability issue is reflected inside WPT tests. Some of these tests assume Blink's behavior (e.g. https://wpt.fyi/results/css/css-position/position-sticky-writing-modes.html ), some of them assume the spec's behavior (e.g. https://wpt.fyi/results/css/css-scroll-snap/snap-inline-block.html ) while others try to deal with inconsistent behaviors (e.g. https://wpt.fyi/results/css/cssom-view/scrollIntoView-vertical-rl-writing-mode.html ).

Do you plan to also remove workaround in existing tests or fix those that assume Blink's incorrect behavior?

This can be a follow up. But I also think it is fair to ask various owners to clean up their tests afterwards. It should be sufficient to file bugs against them.

We will try to remove workaround for tests that use it (at least those we are aware about) and to fix the tests assuming wrong behavior (the patch will make them fail). Currently only detected a limited amount of tests to fix after the patch (about 20 tests)

-- 
Frédéric Wang

[Frédéric Wang]

On 24/07/2019 11:28, Frédéric Wang wrote:

Detecting the wrong behavior is easy: Just check the sign of a scroll position in a rtl scroller at a non-initial position. We don't really have data but there is an old JS query scroll type detector here: https://github.com/othree/jquery.rtl-scroll-type. For example, it is mentioned here: https://stackoverflow.com/questions/24276619/better-way-to-get-the-viewport-of-a-scrollable-div-in-rtl-mode/24394376#24394376 

On 23/07/2019 18:34, Majid Valipour wrote:

Do you plan to also remove workaround in existing tests or fix those that assume Blink's incorrect behavior?

This can be a follow up. But I also think it is fair to ask various owners to clean up their tests afterwards. It should be sufficient to file bugs against them.

Related to that, there is a non-regression test third_party/blink/web_tests/fast/scrolling/jquery-rtl-scroll-type.html that verifies that the jquery script is detects the non-standard behavior for chromium. Since we are going to change to the standard behavior, I guess it makes sense to modify the test accordingly.

-- 
Frédéric Wang

[PhistucK]

While I am very glad this will finally be fixed, I think this really needs a prominent announcement and outreach in any way possible, as not everyone is using feature detection and this can cause confusing and broken behaviors and the bugs could be very hard to find, so whatever you can do to make everyone (in the non-LTR world) know about this would be very appreciated.

Maybe even a console log whenever scrollLeft is accessed and RTL is at play in the first few releases (or a few releases before with an opposite message, in order to forewarn).

(I guess it could cause performance issues? It might be worse it to help developers...)

I fully support this, obviously. Sometimes you need to make hard and breaking changes for the sake of a reasonable and consistent platform.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3cbaf8ad-e30b-e11d-456e-3cdf180326ff%40igalia.com.

[Yoav Weiss]

On Tue, Jul 23, 2019 at 11:47 AM cathie chen <cathi...@igalia.com> wrote:

Contact emails

cathi...@igalia.com, fw...@igalia.com

Explainer

None, scrolling-related JS API have been implemented before the intent-to-* process was in place and discussions happened in the past at the CSS WG:

https://github.com/w3c/csswg-drafts/issues/1354 (non-default CSS direction)

https://github.com/w3c/csswg-drafts/issues/2704 (non-default CSS writing-mode)

It would still be useful when reviewing this intent to have some explanation of what the thing is, destined at folks who aren't highly familiar with the CSSOM View spec.

If there isn't an official one on the spec's repo, writing one in a doc (or even inline here) could go a long way to help reviewers understand the user and developer impact here.

Have you tried to quantify how big is that risk? (e.g. use counters, HTTPArchive data, GH search, etc)

 

Links:

https://bugs.chromium.org/p/chromium/issues/detail?id=721759 

https://bugs.webkit.org/show_bug.cgi?id=172028 

https://bugzilla.mozilla.org/show_bug.cgi?id=1364451 

https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/11996758/ 

https://github.com/w3c/csswg-drafts/issues/1354 

https://github.com/w3c/csswg-drafts/issues/2704 

Ergonomics

Does not apply, this is not a new feature but a behavior change (shifting scroll positions).

Activation

Does not apply, this is not a new feature but a behavior change (shifting scroll positions).

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes: https://wpt.fyi/results/css/cssom-view/scrollLeftTop.html 

Note that this interoperability issue is reflected inside WPT tests. Some of these tests assume Blink's behavior (e.g. https://wpt.fyi/results/css/css-position/position-sticky-writing-modes.html ), some of them assume the spec's behavior (e.g. https://wpt.fyi/results/css/css-scroll-snap/snap-inline-block.html ) while others try to deal with inconsistent behaviors (e.g. https://wpt.fyi/results/css/cssom-view/scrollIntoView-vertical-rl-writing-mode.html ).

I'm assuming you're planning to align those tests. Is that correct?

 

Entry on the feature dashboard

Does not apply, this is not a new feature but a behavior change (shifting scroll positions).

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a4d3e136-5fea-4d4d-9b3c-18a7377ff2e2%40chromium.org.

[Daniel Bratell]

If I understand correctly, this will be a behaviour change that will make a difference to some web developers. Then there should be a chrome status entry. That entry will form the basis for beta blog posts for instance, and gives web developers an official place to track when a certain change goes live and, as PhistucK writes, this sounds like a change that should not happen silently.

Otherwise the main concern here is that the change can break sites, and we need to know how many sites that would be. Or some kind of upper limit on the number of sites. Other people (see yoaw's response)  have suggested ways to get a better understanding about the risk. You could also look at Safari's experiences from changing this.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjw0gQEFrHrMxqXgzV7bLvN054kEy9kKkpAfwVrq37Teg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Joe Medley]

Behavior changes require a dashboard entry, particularly if web sites need to alter their code. Please create an entry.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.z5hkxsd4rbppqq%40cicero2.linkoping.osa.

[bratell]

Hi, 

This was discussed at the weekly API Owner meeting today and we like that you are improving the compatibility, but before we proceed we need a chromestatus entry and a response to the questions asked by Yoav.

Many people reading the chrome status entries (directly of through the blog posts) are probably unfamiliar with vertical text so you should probably keep the entry simple.

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a4d3e136-5fea-4d4d-9b3c-18a7377ff2e2%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjw0gQEFrHrMxqXgzV7bLvN054kEy9kKkpAfwVrq37Teg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

[cathie chen]

Hi,

Thanks for the support! And sorry for the slow response.

Fred and I are preparing for the explainer, the use counters and other entries.

在 2019年7月23日星期二 UTC+8下午11:47:44，cathie chen写道：

[Frédéric Wang]

Hi,

Thanks and sorry for the late reply. Cathie and I agree that we should be more careful before shipping this.

Replying to the points in the thread:

* WPT tests, as I replied to Majid, we plan to fix them for those we are aware of (this includes at least those that will cause new test failures after this change).

* Chrome status entry, we opened one so that we can track this: https://www.chromestatus.com/feature/5759578031521792

* Explainer: a draft is available here: https://people.igalia.com/fwang/scrollable-elements-in-non-default-writing-modes/

* Regarding statistics our idea for now is to use counters when:

   (1) scrollLeft and scrollTop are read for an element that has writing-mode vertical-rl or direction rtl.

   (2) scrollLeft and scrollTop are set to a positive value when they are actually supposed to be ≤ 0 for the element.

   We can probably get similar statistics by other ways but in any case as I mentioned earlier in this thread it is a bit difficult to know what a "wrong" behavior is. For example, it's probably quite common to set scrollLeft and scrollTop to positions that have large absolute values in order to force moving the content to the scroll limits. And scripts and tests performing feature detection are likely to do that too in order to determine whether the browser follows the CSSOM spec or not.

* Making people using other writing modes aware of it: We are not sure yet about this. But it seems we should collect stats before enabling the feature anyway.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d4d3cda7-7bfe-45c8-9c55-76a47b2f9506%40chromium.org.

-- 
Frédéric Wang

[Yoav Weiss]

On Wed, Aug 7, 2019 at 3:28 PM Frédéric Wang <fw...@igalia.com> wrote:

Hi,

Thanks and sorry for the late reply. Cathie and I agree that we should be more careful before shipping this.

Replying to the points in the thread:

* WPT tests, as I replied to Majid, we plan to fix them for those we are aware of (this includes at least those that will cause new test failures after this change).

* Chrome status entry, we opened one so that we can track this: https://www.chromestatus.com/feature/5759578031521792

* Explainer: a draft is available here: https://people.igalia.com/fwang/scrollable-elements-in-non-default-writing-modes/

Thanks for the explainer, it is very helpful! :)

* Regarding statistics our idea for now is to use counters when:

   (1) scrollLeft and scrollTop are read for an element that has writing-mode vertical-rl or direction rtl.

   (2) scrollLeft and scrollTop are set to a positive value when they are actually supposed to be ≤ 0 for the element.

Is (2) applicable only in non-default writing modes? Or all? Can you expand on how you'd know what they are supposed to be?

 

   We can probably get similar statistics by other ways but in any case as I mentioned earlier in this thread it is a bit difficult to know what a "wrong" behavior is. For example, it's probably quite common to set scrollLeft and scrollTop to positions that have large absolute values in order to force moving the content to the scroll limits. And scripts and tests performing feature detection are likely to do that too in order to determine whether the browser follows the CSSOM spec or not.

Will we be able to know when people are detecting Chrome's different behavior and change code based on that?

If not, the stats we'd gather are likely to be an upper bound.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/baad6558-236f-121b-41ec-803fb2fda3bb%40igalia.com.

[Frédéric Wang]

On 08/08/2019 17:52, Yoav Weiss wrote:

* Regarding statistics our idea for now is to use counters when:

   (1) scrollLeft and scrollTop are read for an element that has writing-mode vertical-rl or direction rtl.

   (2) scrollLeft and scrollTop are set to a positive value when they are actually supposed to be ≤ 0 for the element.

Is (2) applicable only in non-default writing modes? Or all? Can you expand on how you'd know what they are supposed to be?

For details, Cathie has started a patch here: https://chromium-review.googlesource.com/c/chromium/src/+/1741776

If you try the tests on the explainer you see that in the default mode, the content of the scrollable elements overflows leftward and downward. In that case the corresponding scrollLeft/scrollTop values are not supposed to be negative. Of course, users can set them to negative values or to very large values and they will be clamped to fit within the scroller limits.

This is similar for other modes, the content may instead overflow leftward (in that case scrollLeft ≤ 0) and/or upward (in that case scrollTop ≤ 0). To know that, we only need to check the CSS writing-wode and direction properties. See the HasLeftwardsDirection and HasUpwardsDirection function from Cathie's patch.

For all modes, including the default mode, we could also count when the users set scrollLeft/scrollTop to negative values when they are not supposed to be or even to a value outside the interval permitted by the scroller. Not sure if that would be helpful here, maybe as a comparison to know how frequent something like this can happen?

BTW, as mentioned on the chromium-review, it should be possible to add a DCHECK when (2) happens in order to collect all the tests that potentially need to be fixed.

 

   We can probably get similar statistics by other ways but in any case as I mentioned earlier in this thread it is a bit difficult to know what a "wrong" behavior is. For example, it's probably quite common to set scrollLeft and scrollTop to positions that have large absolute values in order to force moving the content to the scroll limits. And scripts and tests performing feature detection are likely to do that too in order to determine whether the browser follows the CSSOM spec or not.

Will we be able to know when people are detecting Chrome's different behavior and change code based on that?

If not, the stats we'd gather are likely to be an upper bound.

I'm not sure there is a reliable way to know it. It seems the typical and easiest detection used by the jquery script ( https://github.com/othree/jquery.rtl-scroll-type/blob/master/src/jquery.rtl-scroll.js#L8 ) is just to check that the initial position is > 0 rather than 0. After that, I assume the authors will just always set scrollLeft/scrollTop to nonnegative values. So the only difference with people not doing detection is just one preliminary read operation...

-- 
Frédéric Wang

[Alex Russell]

Hey Frédéric, Cathie:

Just to make sure I understand your last message correctly, should the owners be waiting on updated data generated from that DCHECK?

In general, this seems like a tricky one and I'm happy to see us taking risks here assuming we can roll back quickly if/when we detect major breakage. Is there a plan to guard this behavior with a Finch flag and/or monitor partial rollout?

Regards

[Frédéric Wang]

Hi,

We ran the tests with a DCHECK to verify when scroll coordinates or read/set.

First, only 33 tests set or get scroll coordinates in a non-default writing-mode context (1).

 compositing/overflow/rtl-overflow.html

 compositing/rtl/rtl-overflow-scrolling.html

 external/wpt/animation-worklet/scroll-timeline-writing-modes.https.html

 external/wpt/css/css-flexbox/scrollbars-auto.html

 external/wpt/css/css-flexbox/scrollbars.html

 external/wpt/css/css-position/position-sticky-writing-modes.html

 external/wpt/css/css-scroll-anchoring/text-anchor-in-vertical-rl.html

 external/wpt/css/css-scroll-snap/snap-inline-block.html

 external/wpt/css/cssom-view/scrollIntoView-horizontal-tb-writing-mode-and-rtl-direction.html

 external/wpt/css/cssom-view/scrollIntoView-sideways-lr-writing-mode-and-rtl-direction.html

 external/wpt/css/cssom-view/scrollIntoView-sideways-rl-writing-mode-and-rtl-direction.html

 external/wpt/css/cssom-view/scrollIntoView-vertical-lr-writing-mode-and-rtl-direction.html

 external/wpt/css/cssom-view/scrollIntoView-vertical-rl-writing-mode.html

 external/wpt/css/cssom-view/scrollLeftTop.html

 external/wpt/scroll-animations/current-time-writing-modes.html

 fast/css/overflow-rtl-border-after.html

 fast/events/document-elementFromPoint.html

 fast/events/offsetX-offsetY.html

 fast/overflow/overflow-rtl-vertical-origin.html

 fast/overflow/rtl-scrollbar-drag-origin.html

 fast/overflow/scroll-div-hide-show.html

 fast/scroll-snap/snaps-after-keyboard-scrolling-rtl.html

 fast/scrolling/jquery-rtl-scroll-type.html

 fast/scrolling/overflow-auto-ltr.html

 fast/writing-mode/flipped-block-with-local-background.html

 fast/writing-mode/flipped-blocks-hit-test-overflow-scroll.html

 paint/invalidation/overflow/vertical-overflow-parent.html

 paint/invalidation/overflow/vertical-overflow-same.html

 paint/invalidation/scroll/flipped-blocks-writing-mode-scroll.html

 scrollbars/rtl/div-horizontal-with-vertical-scrollbar.html

 scrollbars/rtl/div-horizontal.html

 scrollbars/rtl/div-vertical.html

 AccessibilityWinBrowserTest.TestCharacterExtentsInEmptyRtlInputField

Among the above tests, only 16 tests actually set a scroll coordinate to a positive value when it should normally be non-positive per the CSSOMView spec (2).

 external/wpt/animation-worklet/scroll-timeline-writing-modes.https.html

 external/wpt/css/css-position/position-sticky-writing-modes.html

 external/wpt/css/css-scroll-anchoring/text-anchor-in-vertical-rl.html

 external/wpt/css/cssom-view/scrollIntoView-vertical-rl-writing-mode.html

 external/wpt/scroll-animations/current-time-writing-modes.html

 fast/overflow/rtl-scrollbar-drag-origin.html

 fast/overflow/scroll-div-hide-show.html

 fast/scroll-snap/snaps-after-keyboard-scrolling-rtl.html

 fast/writing-mode/flipped-blocks-hit-test-overflow-scroll.html

 external/wpt/css/css-flexbox/scrollbars-auto.html

 external/wpt/css/css-flexbox/scrollbars.html

 fast/css/overflow-rtl-border-after.html

 fast/events/document-elementFromPoint.html

 fast/events/offsetX-offsetY.html

 fast/overflow/overflow-rtl-vertical-origin.html

 AccessibilityWinBrowserTest.TestCharacterExtentsInEmptyRtlInputField

One can even restrict the list to 7 tests setting the value outside the scroll boundary (3):

 external/wpt/css/css-flexbox/scrollbars-auto.html

 external/wpt/css/css-flexbox/scrollbars.html

 fast/css/overflow-rtl-border-after.html

 fast/events/document-elementFromPoint.html

 fast/events/offsetX-offsetY.html

 fast/overflow/overflow-rtl-vertical-origin.html

 AccessibilityWinBrowserTest.TestCharacterExtentsInEmptyRtlInputField

Note that sets (1) and (2) correspond to the two counters we introduced in order to find potential suspicious getting/setting of scroll coordinates. Analyzing the tests in more details:

The 7 tests from (3) set a scroll coordinate to a large enough value in order to force scrolling to one edge. It's probably a standard practice even in the default mode. They should be updated to instead to set the coordinate to 0, although they still behave as expected without that change.

There are 2 tests from (2) that try to work around inconsistent behavior between browsers by using feature detection. They still pass but should be updated to remove that workaround now that behavior is interoperable:

fast/scroll-snap/snaps-after-keyboard-scrolling-rtl.html

external/wpt/css/cssom-view/scrollIntoView-vertical-rl-writing-mode.html

The remaining 7 tests from (2) unintentionally perform "illegal" operations and must be updated to follow the standard behavior:

external/wpt/animation-worklet/scroll-timeline-writing-modes.https.html

external/wpt/css/css-position/position-sticky-writing-modes.html

external/wpt/css/css-scroll-anchoring/text-anchor-in-vertical-rl.html

external/wpt/scroll-animations/current-time-writing-modes.html

fast/overflow/rtl-scrollbar-drag-origin.html

fast/overflow/scroll-div-hide-show.html

fast/writing-mode/flipped-blocks-hit-test-overflow-scroll.html

The remaining 17 tests from (1) can be detected without a DCHECK because they affect the test result after trying to switch to the standard behavior. They can be classified as follows:

5 tests set a coordinate to 0 in order to reach a boundary. They should be updated to instead set the coordinate to a large enough negative value. Note that this is the symmetric case of (3) and actually the two flexbox tests from (3) also set a coordinate to 0 in order to reach a boundary and must be updated the same way.

compositing/overflow/rtl-overflow.html

compositing/rtl/rtl-overflow-scrolling.html

paint/invalidation/overflow/vertical-overflow-parent.html

paint/invalidation/overflow/vertical-overflow-same.html

paint/invalidation/scroll/flipped-blocks-writing-mode-scroll.html

1 more test fails after the change and should be updated to follow the standard behavior:

fast/scrolling/overflow-auto-ltr.html

3 tests passed after the change and must be rebased:

external/wpt/css/cssom-view/scrollIntoView-vertical-lr-writing-mode-and-rtl-direction.html

external/wpt/css/cssom-view/scrollIntoView-horizontal-tb-writing-mode-and-rtl-direction.html

external/wpt/css/cssom-view/scrollLeftTop.html

3 tests got improved results after the change and must be rebased:

external/wpt/css/css-scroll-snap/snap-inline-block.html

external/wpt/css/cssom-view/scrollIntoView-sideways-lr-writing-mode-and-rtl-direction.html

external/wpt/css/cssom-view/scrollIntoView-sideways-rl-writing-mode-and-rtl-direction.html

4 tests do not actually check scrolling and must be rebased:

fast/writing-mode/flipped-block-with-local-background.html

scrollbars/rtl/div-horizontal-with-vertical-scrollbar.html

scrollbars/rtl/div-horizontal.html

scrollbars/rtl/div-vertical.html (not changed, this makes it close to expected)

1 test checks jquery feature-detection for scrolling and expects chromium not to follow the standard behavior. It must be updated:

fast/scrolling/jquery-rtl-scroll-type.html ( https://crbug.com/987566 )

Frédéric Wang

[Frédéric Wang]

On 15/08/2019 21:27, 'Alex Russell' via blink-dev wrote:

Hey Frédéric, Cathie:

Just to make sure I understand your last message correctly, should the owners be waiting on updated data generated from that DCHECK?

Sorry for the delay to come back to you. We've just sent a message with an analysis of the affected tests and how we plan to update them.

In general, this seems like a tricky one and I'm happy to see us taking risks here assuming we can roll back quickly if/when we detect major breakage. Is there a plan to guard this behavior with a Finch flag and/or monitor partial rollout?

Correct, https://chromium-review.googlesource.com/c/chromium/src/+/1700001 guards this behavior under a Finch flag.

-- 
Frédéric Wang

[Yoav Weiss]

I just chatted with Frédéric and Cathie. Let me try to sum it up:

• Cathie added UseCounters ([1] [2]) that will give us an upper bound on breakage potential.
• There's no data from these counters just yet, but once we will have data from them, that should give us an idea on the risk level involved.
• If the counters come back with high numbers, that would make it hard for us to estimate breakage without further experiments. In that case, we could try to run a Finch trial and look at the impact on breakage-related metrics.

Given that, I think the API OWNERS can consider this intent on hold until we'd have more data.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/311405ce-d19e-e12e-58f1-dd2c8609d331%40igalia.com.

[Frédéric Wang]

On 02/09/2019 10:39, Yoav Weiss wrote:

I just chatted with Frédéric and Cathie. Let me try to sum it up:

• Cathie added UseCounters ([1] [2]) that will give us an upper bound on breakage potential.
• There's no data from these counters just yet, but once we will have data from them, that should give us an idea on the risk level involved.
• If the counters come back with high numbers, that would make it hard for us to estimate breakage without further experiments. In that case, we could try to run a Finch trial and look at the impact on breakage-related metrics.

Given that, I think the API OWNERS can consider this intent on hold until we'd have more data.

Hi Yoav,

Cathie pointed out to me that we have some data from the use counters.

The first one is about pages using scrollLeft/scrollTop on scrollers with leftward/upward overflow direction. It seems quite big, around 1.5%:

https://chromestatus.com/metrics/feature/timeline/popularity/2998

The second one is for those setting a positive value when the coordinate is expected to be nonpositive. This one seems a bit smaller, below 0.15%

https://chromestatus.com/metrics/feature/timeline/popularity/2999

However, relative to the previous one that's still a ratio of .15/1.5 = one over ten !

So I'm not sure these upper bounds are really helpful so far. Do you think we should wait for more data or do a Finch trial?

-- 
Frédéric Wang

-- 
Frédéric Wang

[Alex Russell]

I can't speak for the other owners, but given the potential risks, a Finch trial seems appropriate. Given that FF and Safari have already shipped this, I'm happy for this to be a majority rollout with a holdback, watched carefully and potentially kill-switched if it goes wrong.

Thanks again for all the care you've put into making sure this lands well!

Regards

[Yoav Weiss]

We discussed this at the API owner meeting today (Chris, Daniel and myself).

The use counters indeed give us an upper bound that's not very useful, which means the only route left towards compatibility is a Finch trial.

At the call, we felt that given the unknown level of breakage, a slightly more cautious approach may be warranted, and a trial with a slow ramp up, as well as user-stickiness, is more likely to catch potential issues before they become too wide spread.

Also, as +PhistucK mentioned previously on this thread, we probably want to do some concentrated outreach in the non-LTR world.

Would it be possible to add console warnings in cases where we suspect breakage might occur?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/79f4223c-f1d0-4a13-ae74-08a18e3fd153%40chromium.org.

[Frédéric Wang]

On 26/09/2019 23:01, Yoav Weiss wrote:

We discussed this at the API owner meeting today (Chris, Daniel and myself).

The use counters indeed give us an upper bound that's not very useful, which means the only route left towards compatibility is a Finch trial.

At the call, we felt that given the unknown level of breakage, a slightly more cautious approach may be warranted, and a trial with a slow ramp up, as well as user-stickiness, is more likely to catch potential issues before they become too wide spread.

Sounds good. Cathie was also mentioned https://www.chromium.org/developers/cluster-telemetry during TPAC but I'm not sure that would really give better results than the current use counters?

Also, as +PhistucK mentioned previously on this thread, we probably want to do some concentrated outreach in the non-LTR world.

Would it be possible to add console warnings in cases where we suspect breakage might occur?

I think so. However, that would probably be similar to the use counter i.e. it is difficult to say that a breakage actually occurs. Maybe it should just be an informative message "the scroll coordinate convention has changed" when scrollLeft/scrollTop are used in non-LTR mode (i.e. similar to the first counter).

-- 
Frédéric Wang

[Majid Valipour]

On Thu, Sep 26, 2019, 5:11 PM Frédéric Wang <fw...@igalia.com> wrote:

On 26/09/2019 23:01, Yoav Weiss wrote:

We discussed this at the API owner meeting today (Chris, Daniel and myself).

The use counters indeed give us an upper bound that's not very useful, which means the only route left towards compatibility is a Finch trial.

At the call, we felt that given the unknown level of breakage, a slightly more cautious approach may be warranted, and a trial with a slow ramp up, as well as user-stickiness, is more likely to catch potential issues before they become too wide spread.

Sounds good. Cathie was also mentioned https://www.chromium.org/developers/cluster-telemetry during TPAC but I'm not sure that would really give better results than the current use counters?

I believe I mentioned this to her. The idea was that it could help build a list of URLs where your usecounter is triggered. Then you can further analyze those to get a sense of how closely the usecounter bound relates to the actual breakage. I suspect the result would confirm that many sites that trigger the usecounter may not actually break which would boost our confidence.

But if API owners feel running a finch trial is safe then no need to use cluster telemetry.

Also, as +PhistucK mentioned previously on this thread, we probably want to do some concentrated outreach in the non-LTR world.

Would it be possible to add console warnings in cases where we suspect breakage might occur?

I think so. However, that would probably be similar to the use counter i.e. it is difficult to say that a breakage actually occurs. Maybe it should just be an informative message "the scroll coordinate convention has changed" when scrollLeft/scrollTop are used in non-LTR mode (i.e. similar to the first counter).

-- 
Frédéric Wang

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4134739d-b52f-f24c-dc3b-6b7ca77eeb44%40igalia.com.

[Yoav Weiss]

On Fri, Sep 27, 2019 at 12:46 AM Majid Valipour <maj...@chromium.org> wrote:

On Thu, Sep 26, 2019, 5:11 PM Frédéric Wang <fw...@igalia.com> wrote:

On 26/09/2019 23:01, Yoav Weiss wrote:

We discussed this at the API owner meeting today (Chris, Daniel and myself).

The use counters indeed give us an upper bound that's not very useful, which means the only route left towards compatibility is a Finch trial.

At the call, we felt that given the unknown level of breakage, a slightly more cautious approach may be warranted, and a trial with a slow ramp up, as well as user-stickiness, is more likely to catch potential issues before they become too wide spread.

Sounds good. Cathie was also mentioned https://www.chromium.org/developers/cluster-telemetry during TPAC but I'm not sure that would really give better results than the current use counters?

I believe I mentioned this to her. The idea was that it could help build a list of URLs where your usecounter is triggered. Then you can further analyze those to get a sense of how closely the usecounter bound relates to the actual breakage. I suspect the result would confirm that many sites that trigger the usecounter may not actually break which would boost our confidence.

That does seem like a good exercise that can increase our confidence in the safety of this change.

A faster option may be to use HTTP archive data to gather URLs that trigger the use counters - seems like this would require waiting for the end of september crawl.

+Rick Viscomi - do you know when that crawl would be available in BQ (and on https://www.chromestatus.com/metrics/feature/timeline/popularity/2998)?

But if API owners feel running a finch trial is safe then no need to use cluster telemetry.

Also, as +PhistucK mentioned previously on this thread, we probably want to do some concentrated outreach in the non-LTR world.

Would it be possible to add console warnings in cases where we suspect breakage might occur?

I think so. However, that would probably be similar to the use counter i.e. it is difficult to say that a breakage actually occurs. Maybe it should just be an informative message "the scroll coordinate convention has changed" when scrollLeft/scrollTop are used in non-LTR mode (i.e. similar to the first counter).

-- 
Frédéric Wang

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4134739d-b52f-f24c-dc3b-6b7ca77eeb44%40igalia.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB8RdXuMzzQZXnuDhZ%3Dfmhz%3D8k_GgWV5ANgyHVe4_9J_NdwTDA%40mail.gmail.com.

[Frédéric Wang]

On 27/09/2019 11:36, Daniel Bratell wrote:
> I do not think there is a safe option here, so anything that can help
> us reduce the risk and increase the understanding would be valuable.
>
> The current use counter is at 1.5% which is 500x higher than the
> regular "this will be fine" limit. I don't expect the sites that
> trigger the use counter to actually break, but it's very hard to know
> for sure. Just play it safe. Since it has worked out for WebKit I
> suspect it will be fine, but we cannot know for sure.
>
Not disagreeing with your point, but just for clarification: There are
actually two counters. One case is about scrollLeft/scrollTop used in
non-default writing modes (which does not indicate any mistake) and a
subcase is when one of this coordinate is set to a positive value that
is actually out-of-bound for that writing mode (which *might* indicate a
mistake). The second counter was at .15% last time I checked, which is
still 50x higher that the "this will be fine" limit and 10% of the first
counter.

--
Frédéric Wang

[Daniel Bratell]

On 2019-09-27 06:26, Yoav Weiss wrote:

On Fri, Sep 27, 2019 at 12:46 AM Majid Valipour <maj...@chromium.org> wrote:

On Thu, Sep 26, 2019, 5:11 PM Frédéric Wang <fw...@igalia.com> wrote:

On 26/09/2019 23:01, Yoav Weiss wrote:

We discussed this at the API owner meeting today (Chris, Daniel and myself).

The use counters indeed give us an upper bound that's not very useful, which means the only route left towards compatibility is a Finch trial.

At the call, we felt that given the unknown level of breakage, a slightly more cautious approach may be warranted, and a trial with a slow ramp up, as well as user-stickiness, is more likely to catch potential issues before they become too wide spread.

Sounds good. Cathie was also mentioned https://www.chromium.org/developers/cluster-telemetry during TPAC but I'm not sure that would really give better results than the current use counters?

I believe I mentioned this to her. The idea was that it could help build a list of URLs where your usecounter is triggered. Then you can further analyze those to get a sense of how closely the usecounter bound relates to the actual breakage. I suspect the result would confirm that many sites that trigger the usecounter may not actually break which would boost our confidence.

That does seem like a good exercise that can increase our confidence in the safety of this change.

A faster option may be to use HTTP archive data to gather URLs that trigger the use counters - seems like this would require waiting for the end of september crawl.

+Rick Viscomi - do you know when that crawl would be available in BQ (and on https://www.chromestatus.com/metrics/feature/timeline/popularity/2998)?

But if API owners feel running a finch trial is safe then no need to use cluster telemetry.

I do not think there is a safe option here, so anything that can help us reduce the risk and increase the understanding would be valuable.

The current use counter is at 1.5% which is 500x higher than the regular "this will be fine" limit. I don't expect the sites that trigger the use counter to actually break, but it's very hard to know for sure. Just play it safe. Since it has worked out for WebKit I suspect it will be fine, but we cannot know for sure.

/Daniel

[PhistucK]

Is there a flag that can be set to start testing websites?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b8b40f24-1e50-8ef3-5c9f-f4c5b238eaa2%40igalia.com.

[cathiechen]

在 2019年9月28日，下午11:07，PhistucK <phis...@gmail.com> 写道：

Is there a flag that can be set to start testing websites?

☆PhistucK

We have a runtime flag (EnableCSSOMViewScrollCoordinates) with Finch trial supported in the patch. https://chromium-review.googlesource.com/c/chromium/src/+/1700001

[Rick Viscomi]

+Rick Viscomi - do you know when that crawl would be available in BQ (and on https://www.chromestatus.com/metrics/feature/timeline/popularity/2998)?

Should be available on Tuesday.

[Frédéric Wang]

On 27/09/2019 17:21, Frédéric Wang wrote:
> Not disagreeing with your point, but just for clarification: There are
> actually two counters. One case is about scrollLeft/scrollTop used in
> non-default writing modes (which does not indicate any mistake) and a
> subcase is when one of this coordinate is set to a positive value that
> is actually out-of-bound for that writing mode (which *might* indicate a
> mistake). The second counter was at .15% last time I checked, which is
> still 50x higher that the "this will be fine" limit and 10% of the first
> counter.

Note that the 1st counter (reading scrollLeft/scrollTop values for
scrollers in non-default writing mode) is still relevant to know pages
that might potentially break, even if that does not indicate any mistake
per the CSSOM spec. So it would probably help to collect and analyze
them too.

--
Frédéric Wang

[PhistucK]

For what it is worth, it seems like GWT Web Toolkit (formerly Google Web Toolkit or just GWT) used/uses browser detection for this, which is used by some large enterprise product in Israel.

I cannot verify that it is broken until that flag is implemented, though. Any timeframe?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aec82bb0-ff4c-04b4-7bc3-2e275379ae87%40igalia.com.

[PhistucK]

Thank you for landing this.

What are the plans regarding forewarning and outreach?

☆PhistucK

[cathiechen]

在 2019年10月10日，下午4:29，PhistucK <phis...@gmail.com> 写道：

Thank you for landing this.

What are the plans regarding forewarning and outreach?

Yes, we've landed the patch with cssomViewScrollCoordinates disabled by default. It can be enabled by either the --enable-experimental-web-platform-features or --enable-cssom-view-scroll-coordinates.

Based on what we discussed in this thread, it seems there're two ways we can try to understand the risk:

1. Try to collect samples for topmost websites, and analysis some of them.

2. Because it's hard to detect the failures in pages, try to enable the flag to a small part of users, and try to get feedback.

Cathie

[PhistucK]

The problem with enabling it for a small part of the users is that they may not report the breakage to anyone and even if they do, their report (to the website) may/will be dismissed by the website authors as "cannot reproduce".

Remember that this only affects non-left-to-right-top-to-bottom people.

Orthogonal - maybe the trial should mainly target users in probably-affected countries (otherwise it may not practically affect anyone). 

I am doing my part by telling fellow Israeli developers about this, but I have a fairly small crowd anyway and Israel is just a small percentage, compared to the rest of the potentially affected population (Arabic speaking countries and some more).

I hope this goes well. I would hate it if the future continues to be non-interoperable.

(By the way, even though it is too late into the game, I never liked this negative-value solution. It makes it hard to write direction-agnostic code. I still prefer that over lack of interoperability, but it is not my preferred solution of the available options)

☆PhistucK

[Alex Russell]

Hey everyone,

The OWNERs met today with Cathie and Frédéric, and I'd like to personally thank them for taking super late/early calls to make the conversation happen.

Per the call, I think that Dan, Yoav, and I are happy to conditionally LGTM this based on the plan discussed in the call:

1. Launch should be finch-gated, starting at a low fraction and ramping up over the course of the release. That should get us (over a few weeks) a good solution to PhistucK's concern (which I share).
2. UKM for affected origins should be put in place to help improve understanding of affected origins in case we need to pause/revert the rollout
3. In parallel, Cathie and Frédéric to dig into why the HTTPArchive data doesn't show an affected percentage and, assuming we get to the bottom of it, analyse affected origins for compatibility.

Given the fact that other engines have already shipped the proposed behavior, the window of potential impact seems small enough (UA-detecting sites/code) that the above seems like a good way to balance the potential risks. Yoav is going to help ensure that there's outreach about this behavior change.

Contingent all the above, LGTM1.

Thanks to everyone who has participated here!

Regards

[Yoav Weiss]

LGTM2

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ce90da1e-c639-4ae1-9cf7-164d7fdada39%40chromium.org.

[Daniel Bratell]

LGTM3 to the plan outlined by Alex.

This is a valuable change, aligning Blink with other browsers and the spec, but it's hard to get a grip on the risk of code written specifically for Blink breaking so we need that careful launch.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhJ0FjUr6WiuELaprCJYEfpxxqrGXnh1YNZ%3D_s5bKCsFg%40mail.gmail.com.

[bkar...@gmail.com]

As to why the HTTPArchive bit isn't showing data, I spoke to +Rick Viscomi and we have a probable reason - looking into it.  It's almost certainly not 0 though.

[Frédéric Wang]

On 24/10/2019 21:57, 'Alex Russell' via blink-dev wrote:
> In parallel, Cathie and Frédéric to dig into why the HTTPArchive data
> doesn't show an affected percentage and, assuming we get to the bottom
> of it, analyse affected origins for compatibility.

We investigated this during BlinkOn and it seems it is just because the
counters were not available yet:

https://github.com/WPO-Foundation/webpagetest/issues/1308#issuecomment-554642562

We will analyze origins when we get the data from HTTPArchive.

--
Frédéric Wang

[Frédéric Wang]

On 24/10/2019 21:57, 'Alex Russell' via blink-dev wrote:

Hey everyone,

The OWNERs met today with Cathie and Frédéric, and I'd like to personally thank them for taking super late/early calls to make the conversation happen.

Per the call, I think that Dan, Yoav, and I are happy to conditionally LGTM this based on the plan discussed in the call:

1. Launch should be finch-gated, starting at a low fraction and ramping up over the course of the release. That should get us (over a few weeks) a good solution to PhistucK's concern (which I share).
2. UKM for affected origins should be put in place to help improve understanding of affected origins in case we need to pause/revert the rollout
3. In parallel, Cathie and Frédéric to dig into why the HTTPArchive data doesn't show an affected percentage and, assuming we get to the bottom of it, analyse affected origins for compatibility.

Given the fact that other engines have already shipped the proposed behavior, the window of potential impact seems small enough (UA-detecting sites/code) that the above seems like a good way to balance the potential risks. Yoav is going to help ensure that there's outreach about this behavior change.

Contingent all the above, LGTM1.

Thanks to everyone who has participated here!

Regards

Hi everybody,

Cathie and I took a look at the top results from HTTPArchive. As expected, this is a bit tricky to understand. We used Mozilla's testcase reducer (Lithium) to simplify the pages that trigger the counters at startup.

Most websites seem to use non-default writing modes for the text (Hebrew, Arabic, Asian, ...) and to rely on third-party JS libraries (e.g jquery modules). Reductions lead to a few HTML elements involved, including the relevant <script> tags. A first conclusion is that it is probably better to reach the developers of these libraries rather than contacting the web page authors.

So far we found two cases that appear quite regularly (for both counters) but are not affected by our change:

* https://github.com/KingSora/OverlayScrollbars

  This has a rtlScrollBehavior() function that intentionally sets a RTL

  scroller to a positive scrollLeft in order to perform feature detection.

  This means that it does trigger the counter but our change won't cause any

  breakage.

* https://github.com/sdecima/javascript-detect-element-resize

  https://github.com/procurios/ResizeSensor and similar libraries implementing

  a ResizeObserver by wrapping elements into a scroller. These libraries

  already have bug reports saying that they don't work in RTL mode, so

  our change won't make things worse here. Probably we should encourage users to

  switch to native ResizeObserver when available anyway.

This first analysis seems to confirm the idea that the counters are mostly false positive (remember that something as basic as scrollLeft += 5 may trigger the counters). So the finch-gated approach that Alex suggested is probably more reliable than relying on the counter bound and HTTPArchive. Do Google engineers have more information about the finch-gated result?

-- 
Frédéric Wang

[Philip Jägenstedt]

This is my first appearance on this intent, but I wanted to say this httparchive analysis is great, it's always fun/relieving to see when high usage looks like mostly false positives.

Did you get anybody to help you with finch?

[Frédéric Wang]

On 16/01/2020 18:20, Philip Jägenstedt wrote:

This is my first appearance on this intent, but I wanted to say this httparchive analysis is great, it's always fun/relieving to see when high usage looks like mostly false positives.

Did you get anybody to help you with finch?

Hi Philip, thanks for the kind words and sorry for the slow response, I missed your reply. No we didn't get any update on the finch flag, we're are still interested in hearing from API owner about how to proceed here.

-- 
Frédéric Wang

[Philip Jägenstedt]

I'm more sorry!

+Chris Harrelson +Navid Zolghadr +David Bokan, scrolling is in the intersection of rendering and input. Is there someone from either teams that could help Frédéric set up the finch experiment and ramp it up to launch this?

[David Bokan]

I've been involved in some of the code changes so our team can help setting up the launch.

I'd like to confirm the plan based on Alex's message above:

1. Launch should be finch-gated, starting at a low fraction and ramping up over the course of the release. That should get us (over a few weeks) a good solution to PhistucK's concern (which I share).
2. UKM for affected origins should be put in place to help improve understanding of affected origins in case we need to pause/revert the rollout
3. In parallel, Cathie and Frédéric to dig into why the HTTPArchive data doesn't show an affected percentage and, assuming we get to the bottom of it, analyse affected origins for compatibility.

It sounds like #3 is done.

For #2, this would be to allow per-origin tracking of pages that hit the use counters (for non-LTR/non-TB scrollers, whether script reads or sets to a positive value).  Based on the analysis in #3 it seems like the false-positive rate is pretty high. Is the expectation that if we see a higher-than expected value for the use counters in UMA, we'd use the UKM to manually verify that most of the top origins are false-positives?

For #1, a typical Finch-based launch is 50% during beta then start at 1% on stable and ramp up to 100% if nothing goes wrong. Did we want a slower rollout for this feature? e.g. in stable 1% for a week, 10% for a week, 50% for a week, 100%? Should we try 100% beta to maximize chances we catch major regressions before the stable rollout? Did we want to scope these percentages to non-LTR language geos?

[Frédéric Wang]

On 20/02/2020 15:31, David Bokan wrote:

I've been involved in some of the code changes so our team can help setting up the launch.

I'd like to confirm the plan based on Alex's message above:

1. Launch should be finch-gated, starting at a low fraction and ramping up over the course of the release. That should get us (over a few weeks) a good solution to PhistucK's concern (which I share).
2. UKM for affected origins should be put in place to help improve understanding of affected origins in case we need to pause/revert the rollout
3. In parallel, Cathie and Frédéric to dig into why the HTTPArchive data doesn't show an affected percentage and, assuming we get to the bottom of it, analyse affected origins for compatibility.

It sounds like #3 is done.

Hi,

Apologies for the miscommunication. Majid has been helping us on the this (thanks!). Here is a document with more information:

https://docs.google.com/document/d/1L44vmCJ5WKoWu3ZZxMEM-sugP9s-fEFH_hOuojI_H6k

For #2, this would be to allow per-origin tracking of pages that hit the use counters (for non-LTR/non-TB scrollers, whether script reads or sets to a positive value).  Based on the analysis in #3 it seems like the false-positive rate is pretty high. Is the expectation that if we see a higher-than expected value for the use counters in UMA, we'd use the UKM to manually verify that most of the top origins are false-positives?

This is done in https://chromium-review.googlesource.com/c/chromium/src/+/2055350

We have plan to analyze the origins. One idea would be to do similar automated testcase reduction and manual analysis for the 100 URLs. We already did that for HTTPArchive (~20 URLs) so that should be fine. Majid also proposed to do some automated comparison of pages with and without the flag enabled, to at least detect potential regressions.

For #1, a typical Finch-based launch is 50% during beta then start at 1% on stable and ramp up to 100% if nothing goes wrong. Did we want a slower rollout for this feature? e.g. in stable 1% for a week, 10% for a week, 50% for a week, 100%? Should we try 100% beta to maximize chances we catch major regressions before the stable rollout? Did we want to scope these percentages to non-LTR language geos?

This is discussed a bit on the google doc. I admit I'm not familiar with these so not sure I can really comment. But IIUC Majid thinks it's better to do a fast rollout to increase the change of finding regressions (counter likely only gives false positives) and to avoid that users see weird non-reproducible regressions.

The behavior is unchanged for LTR and horizontal-tb pages, so I think it's not a big problem to enable the flag for these users. However, we can consider the ratio kElementWithLeftwardOrUpwardOverflowDirection_ScrollLeftOrTopSetPositive / kElementWithLeftwardOrUpwardOverflowDirection_ScrollLeftOrTop if we want percentage relative to pages that might actually be affected.

-- 
Frédéric Wang

[David Bokan]

Great, all that sounds good to me. Thanks Majid! 

[Majid Valipour]

Hi all,

I wanted to give an update on this feature launch and ask for API OWNERs to ship this.

We have used UMA/UKM to collect data for the past 6 months on possible breakage and have analyzed them. Below is the summary of the full report.

UMA/UKM Analysis result:

About 0.1% of page visits hit the key feature counter (UMA link). UKM data total 2072 unique domains that have reported the feature usage between 2020-01-01 and 2020-06-15. We manually reviewed ~10% of these (top 100 domains with the highest rate of hitting the feature and top 100 most popular). In cases where we managed to reproduce the behavior, less than 2% are actually affected and up to 4% (when considering cases where it is not clear if they are affected or not). In other words, about 96% false positive rate. This result matches the previous HttpArchive analysis in which the vast majority of cases were false positives as well.

Most false positives were feature detection scripts which are not affected by the change (see common examples). The most common culprit of the true positive is AMP Carousel v1.0 when used in a page with non-default writing mode. In this case, the change in behavior is not dramatic (basically the carousel starts from the wrong slide). We have reached out to the AMP team to notify them and this issue does not affect the latest version AMP Carousel (v2.0).

If we apply the 2%-4% true positive rate to the total count from UMA. The ballpark estimate is that 0.002% - 0.004% of page visits may be affected. We expect that the impact on those pages UX to be fairly minimal.

Recommendation:

We recommend shipping this feature to bring Chromium behavior in line with Firefox and Safari. We will work with the AMP team to address Carousel v1 logic if needed. The current plan is to use Finch to launch to the stable channel (M85+) and monitor scrolling related bugs to pull back if risk is higher than expected.

Thanks

Majid

[Alex Russell]

Thanks so much for doing this analysis; looks great from my perspective. Excited to see this roll out!