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).
--
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.
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?
> 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.
-- Frédéric Wang
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
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
--
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.
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)
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).
--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjw0gQEFrHrMxqXgzV7bLvN054kEy9kKkpAfwVrq37Teg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.z5hkxsd4rbppqq%40cicero2.linkoping.osa.
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.
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
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.
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.
* 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
Frédéric Wang
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?
Correct, https://chromium-review.googlesource.com/c/chromium/src/+/1700001 guards this behavior under a Finch flag.
-- 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/311405ce-d19e-e12e-58f1-dd2c8609d331%40igalia.com.
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
--
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.
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
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
--
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.
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.
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.
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
--
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.
在 2019年9月28日,下午11:07,PhistucK <phis...@gmail.com> 写道:Is there a flag that can be set to start testing websites?☆PhistucK
+Rick Viscomi - do you know when that crawl would be available in BQ (and on https://www.chromestatus.com/metrics/feature/timeline/popularity/2998)?
--
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.
--
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.
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.
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:
- 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).
- 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
- 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
-- Frédéric Wang
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
- 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).
- 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
- 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.
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:
- 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).
- 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
- 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
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.