Intent To Ship: Prevent fixed elements from moving during elastic overscroll.

[Rahul Arakeri]

Contact emails: ara...@microsoft.com 

 

CSSWG discussion: [css-overscroll] Whether to move position:fixed elements during overscrolling · Issue #6299 · w3c/csswg-drafts (github.com) 

 

Summary: Currently, position:fixed elements move when the scroller is overscrolled. With this change, we intend to prevent fixed elements from moving during an elastic overscroll.

 

Blink component: Blink>Scroll 

 

Chromestatus: Prevent overscroll for fixed elements. - Chrome Platform Status (chromestatus.com)

 

Risks:

• Interoperability: Firefox/Safari still moves fixed elements on overscroll. Interacting with websites will feel different (going forward) on platforms that support overscroll. This may lead to some web devs amending pages to preserve their original UX. We are currently running experiments in Microsoft Edge to determine user impact and would also discuss the possibility of doing origin trials in Chromium with Google engineers.

 

Debuggability: N/A 

Is this feature fully tested by web-platform-tests? 

Yes. We did a dry run with the feature turned on and noticed test failures. They will need to be addressed before the feature can be turned on. 

Flag name: FixedElementsDontOverscroll

• Usage: chrome.exe --enable-features=ElasticOverscroll --enable-blink-features=FixedElementsDontOverscroll

 

Estimated milestone: 

105 

 

Tracking bugs:

• Chromium:
• 585766 - Overscroll shouldn't affect fixed elements - chromium
• Firefox:
• https://github.com/mozilla/wg-decisions/issues/757
• https://bugzilla.mozilla.org/show_bug.cgi?id=1760368
• Webkit:
• https://bugs.webkit.org/show_bug.cgi?id=206227

 

Misc:

• BlinkOn 16 talk: (1311) Keynote Presentation & Lightning Talks - Session 1 [BlinkOn 16] - YouTube

[Robert Flack]

On Tue, May 24, 2022 at 1:27 PM 'Rahul Arakeri' via input-dev <inpu...@chromium.org> wrote:

Contact emails: ara...@microsoft.com 

 

CSSWG discussion: [css-overscroll] Whether to move position:fixed elements during overscrolling · Issue #6299 · w3c/csswg-drafts (github.com) 

 

Summary: Currently, position:fixed elements move when the scroller is overscrolled. With this change, we intend to prevent fixed elements from moving during an elastic overscroll.

 

Blink component: Blink>Scroll 

 

Chromestatus: Prevent overscroll for fixed elements. - Chrome Platform Status (chromestatus.com)

 

Risks:

• Interoperability: Firefox/Safari still moves fixed elements on overscroll.

Just wanted to clarify, iOS Safari does not move fixed position elements on overscroll except when you start scrolling at the scroller edge in order to make room for the refresh affordance, so there's already some inconsistency here. 

Also it is considered a bug that fixed content does still move on Safari desktop so they would likely be willing to follow along with this change.

[Yoav Weiss]

Hey Rahul!

A few things missing with the intent:

• An explainer would be helpful to clarify the motivation for this and if this has any web exposed impact (and e.g. how would developers that want to keep to current behavior could cope with different engines doing different things)
• Is this specified? I see the WG discussion, but not sure if a spec change followed
• Can you ask for official Mozilla and WebKit positions? (https://bit.ly/blink-signals)

Cheers :)

Yoav

--
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/CAJh39TOdn6Hksb1Zb8H5oqsUu0xvS%2BmqvypEghDsNtsQRFr1Nw%40mail.gmail.com.

[Ben Mathwig]

Explainer

Are the links to open bugs on Mozilla and WebKit an indication of position? It looks like comments on these threads point towards a positive position.

--Ben

[Chris Harrelson]

On Fri, May 27, 2022 at 11:38 AM 'Ben Mathwig' via blink-dev <blin...@chromium.org> wrote:

Explainer

Are the links to open bugs on Mozilla and WebKit an indication of position? It looks like comments on these threads point towards a positive position.

No. it has to be done via the https://bit.ly/blink-signals process, because otherwise we might accidentally misconstrue their true organizational positions.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5f89f3bd-399d-44b5-a8de-747181df317cn%40chromium.org.

[Emilio Cobos Álvarez]

On 5/27/22 20:40, Chris Harrelson wrote:
> No. it has to be done via the https://bit.ly/blink-signals
> <https://bit.ly/blink-signals> process, because otherwise we might
> accidentally misconstrue their true organizational positions.

FWIW in case it saves some time, we're actively working on this in
<https://bugzilla.mozilla.org/show_bug.cgi?id=1760368>.

-- Emilio

[Chris Harrelson]

Ah yes! That counts, and saves filing a signal. Thanks Emilio!

--
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/5f816069-432f-b85a-4abc-ada3ea0dc71f%40mozilla.com.

[Yoav Weiss]

Thanks for the explainer. My question regarding a spec still stands :)

On Friday, May 27, 2022 at 10:49:31 PM UTC+2 Chris Harrelson wrote:

Ah yes! That counts, and saves filing a signal. Thanks Emilio!

On Fri, May 27, 2022 at 1:46 PM Emilio Cobos Álvarez <emi...@mozilla.com> wrote:

On 5/27/22 20:40, Chris Harrelson wrote:
> No. it has to be done via the https://bit.ly/blink-signals
> <https://bit.ly/blink-signals> process, because otherwise we might
> accidentally misconstrue their true organizational positions.

FWIW in case it saves some time, we're actively working on this in
<https://bugzilla.mozilla.org/show_bug.cgi?id=1760368>.

-- Emilio

--
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+unsubscribe@chromium.org.

[Chris Harrelson]

A spec edit is indeed needed. However, I think it's a one-liner. I pinged the editor of the spec just now about it.

LGTM1 to ship; I'll make sure that the spec commit lands via my CSSWG hat.

On Wed, Jun 1, 2022 at 12:45 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for the explainer. My question regarding a spec still stands :)

On Friday, May 27, 2022 at 10:49:31 PM UTC+2 Chris Harrelson wrote:

Ah yes! That counts, and saves filing a signal. Thanks Emilio!

On Fri, May 27, 2022 at 1:46 PM Emilio Cobos Álvarez <emi...@mozilla.com> wrote:

On 5/27/22 20:40, Chris Harrelson wrote:
> No. it has to be done via the https://bit.ly/blink-signals
> <https://bit.ly/blink-signals> process, because otherwise we might
> accidentally misconstrue their true organizational positions.

FWIW in case it saves some time, we're actively working on this in
<https://bugzilla.mozilla.org/show_bug.cgi?id=1760368>.

-- Emilio

--
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/5f816069-432f-b85a-4abc-ada3ea0dc71f%40mozilla.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/4191983d-d0fd-4dce-beed-d12ee7115a46n%40chromium.org.

[Mike Taylor]

Thanks Chris. LGTM2.

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

[Chris Harrelson]

Spec text.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5efc25ed-0c43-4c7d-e877-d05b6a0512f3%40chromium.org.

[Yoav Weiss]

LGTM3

[Rahul Arakeri]

The failing tests have now been fixed. Thanks for the quick review Chris !

Now that this is done, can you please tell me what the process would look like to get this ON in stable? I have a CL for this but I assume you’d want to run experiments first?

 

Thanks,

Rahul

[Daniel Bratell]

You have the approval needed for shipping on stable, i.e. land that patch. It will get some testing by going through Canary and Beta releases, but if you feel some uncertainty you can also add the plumbing that would let it be turned off remotely (flags, finch). You will need some assistance by Google employees for that though.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SJ0PR00MB1141ACDFA8EA11EAF30D96B3A6A29%40SJ0PR00MB1141.namprd00.prod.outlook.com.

[Rahul Arakeri]

Thanks Daniel, the CL has landed !

Also, I had added a base::Feature flag a couple of weeks ago. I’m assuming that should make it controllable remotely. If not, please let me know.

 

PS: Thank you all for your reviews on this feature. We appreciate it… 😊

I will keep an eye out for any issues that pop up in the coming days.

 

Thanks,

Rahul

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1985d9a0-04e9-f1f3-75d4-c398b28455dd%40gmail.com.