Closed Bug 1779909 Opened 2 years ago Closed 2 years ago

CSS Scroll Snap re-snapping happens while user is still sliding fingers on trackpad

Categories

(Core :: Layout: Scrolling and Overflow, defect, P2)

Firefox 104
defect

Tracking

()

VERIFIED FIXED
104 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox-esr102 --- unaffected
firefox102 --- unaffected
firefox103 --- unaffected
firefox104 --- verified

People

(Reporter: sime.vidas, Assigned: hiro)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:104.0) Gecko/20100101 Firefox/104.0

Steps to reproduce:

Scroll snap re-snapping was implemented in Firefox Nightly earlier this month.

I have added scroll snap to my Twitter timeline via the Stylus add-on. When re-snapping landed in Firefox Nightly, it became impossible for me to view the bottom half of tweets that are higher than my viewport because re-snapping is too forceful.

I have posted a screencast of the issue on Youtube: https://www.youtube.com/watch?v=bSJyg7DKqAc

This happens when I scroll using my laptop’s trackpad or the Space bar key.

The user styles that I’m adding to the Twitter timeline (https://twitter.com/home URL):

html {
    scroll-snap-type: y proximity !important;
}

article {
    scroll-snap-align: start !important;
    scroll-margin: 53px !important;
}

As you can see, the code couldn’t be simpler. I apply proximity snapping to the page and then snap to the start of the tweets in the timeline (which are <article> elements). The scroll margin is there because of Twitter’s sticky header.

I am not sure why Firefox is re-snapping so aggressively (as my linked video shows). Maybe Twitter is mutating the DOM too often (due to the virtual scroller). If possible, I would like to be able to disable re-snapping. I prefer the behavior in Firefox release, which doesn’t have re-snapping yet.

Regressed by: 1530253

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Scrolling and Overflow' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Layout: Scrolling and Overflow
Keywords: regression
Product: Firefox → Core

I have tested on another website with a static grid, and I have found that Firefox re-snaps while I’m still sliding my fingers on the trackpad. Chrome correctly only re-snaps after I’ve lifted my fingers from the trackpad.

I have recorded a video of this issue: https://www.youtube.com/watch?v=EmL0CllMB6s

It shows the same operation in Chrome and Firefox. Notice how Firefox re-snaps while I’m still slowly scrolling down the page.

I will update the title of this bug to make it more general.

Set release status flags based on info from the regressing bug 1530253

:hiro, since you are the author of the regressor, bug 1530253, could you take a look?
For more information, please visit auto_nag documentation.

Flags: needinfo?(hikezoe.birchill)
Summary: CSS Scroll Snap re-snapping is too forceful on Twitter timeline → CSS Scroll Snap re-snapping happens while user is still sliding fingers on trackpad

If you would like to test on H&M’s website yourself, the CSS for the Stylus add-on is this:

html {
    scroll-snap-type: y proximity !important;
}

.product-item {
    scroll-snap-align: start !important;
    scroll-margin-top: 75px !important;
}

The page that I’ve tested on is https://www2.hm.com/en_eur/men/new-arrivals/view-all.html

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true

(In reply to Šime Vidas from comment #2)

I have tested on another website with a static grid, and I have found that Firefox re-snaps while I’m still sliding my fingers on the trackpad. Chrome correctly only re-snaps after I’ve lifted my fingers from the trackpad.

That sounds weird. We only try to snap (not resnap) only on PanEnd which means the user left their fingers from the touchpad. Also note that re-snapping happens only when some content (layout) is changed. It's not directly related to user's input.

Does changing layout.css.scroll-snap.proximity-threshold value mitigate your problem? If so, we need to tweak the value less eager in bug 1766386.

Flags: needinfo?(hikezoe.birchill) → needinfo?(sime.vidas)

I don’t know what is going on, but the re-snapping is definitely happening while my fingers are still touching the touchpad. Changing the proximity threshold (I tried 500 and 0) did not help. Maybe there’s something wrong with my laptop.

Please try to re-produce if you have a Macbook.

  1. Open Firefox Nightly in troubleshoot mode (if necessary)

  2. Navigate to this page: https://www2.hm.com/en_eur/men/new-arrivals/view-all.html

  3. Run this code in the JavaScript console to inject the scroll snap styles into the page

    document.head.insertAdjacentHTML('beforeend', `<style>
    html {
    scroll-snap-type: y proximity !important;
    }

    .product-item {
    scroll-snap-align: start !important;
    scroll-margin-top: 75px !important;
    }
    </style>`)

  4. Using two fingers, very slowly slide up on the laptop’s touchpad for multiple seconds, without lifting your fingers. Perform this step multiple times.

Here’s another video of what happens when I follow these exact steps: https://www.youtube.com/watch?v=JJmpEw1cX7M

It seems that Firefox is re-snapping at a very high rate, multiple times per second, all while my fingers keep touching and sliding on the touchpad.

Flags: needinfo?(sime.vidas)

Oh okay. Now I am realized (by your comments) that there's a condition where we need to clobber the last snap target id(s), that is when any user input started scrollling we need to clobber them. I will try it out.

Assignee: nobody → hikezoe.birchill
Severity: -- → S2
Status: NEW → ASSIGNED
Priority: -- → P2

(In reply to Hiroyuki Ikezoe (:hiro) from comment #9)

Oh okay. Now I am realized (by your comments) that there's a condition where we need to clobber the last snap target id(s), that is when any user input started scrollling we need to clobber them. I will try it out.

I also realized that this isn't going to fix the issue here at all. We do skip re-snapping if there's any async scroll is operating, but in the case of pan scrolling, it's not async. We probably need to propagate whether it's during panning or not from APZ to the main-thread via RepaintRequest.

Šime, would you mind trying this build to see whether the problem is fixed or not? You can download target.dmg in the "Artifacts and Debugging Tools" pane. On my local mac book I can no longer see any jumps with the step in comment 8. Thanks!

Flags: needinfo?(sime.vidas)

I tested with this build. It seems to work quite well. My original issue is no longer present.

However, I have noticed another issue, which I’ve recorded in this video: https://www.youtube.com/watch?v=AFMj8w3g1Jg

As you can see, when I scroll the page, and the scroll ends in a position that is outside the proximity threshold for snapping (so, the page is not snapped), then if I move the mouse cursor to hover a product item in the grid, snapping suddenly happens on hover. This seems like a bug. If snapping didn’t happen at the end of the scrolling operation, it should not happen on mouse hover. It’s not a good user experience.

Flags: needinfo?(sime.vidas)

Thank you! I filed bug 1780154 for it.

I've finished writing a fix, but haven't finished writing a good test. I have to figure out a way to tell smooth animation for snapping has finished.

Attachment #9286142 - Attachment description: WIP: Bug 1779909 - Skip re-snapping during pan gesture. → Bug 1779909 - Skip re-snapping during pan/touch gestures or scrollbar dragging. r?botond
Pushed by hikezoe.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/78a43d5ba28e
Skip re-snapping during pan/touch gestures or scrollbar dragging. r=botond
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 104 Branch

I have discovered another small issue. Could you check if this is a bug?

Video recording of potential bug: https://www.youtube.com/watch?v=qAc1ltTFFVg

So these are my scroll snap user styles on the Twitter timeline in the latest Firefox Nightly. I really like the latest improvements 👍, but when I perform a zoom gesture on my laptop’s trackpad (either two-finger double tap or pinch to zoom), Firefox re-snaps immediately after the page is zoomed. This seems like a bug.

(In reply to Šime Vidas from comment #18)

So these are my scroll snap user styles on the Twitter timeline in the latest Firefox Nightly. I really like the latest improvements 👍, but when I perform a zoom gesture on my laptop’s trackpad (either two-finger double tap or pinch to zoom), Firefox re-snaps immediately after the page is zoomed. This seems like a bug.

Is the issue only observable on Twitter? I tried it on H&M, but can't reproduce. (I also tried on a Twitter search result page, but can't see the issue there either). Rather I found a different issue (bug 1780701) which happens when double tap zoom didn't happen.

I have discovered that the issue shown in my previous comment only occurs if I use scroll-behavior: smooth on the page (<html> element).

Steps to reproduce:

  1. Open https://twitter.com/home

  2. Run this code in the JavaScript console to inject the scroll snap styles to the page:

    document.body.insertAdjacentHTML('beforeend', `
    <style>
    html {
        scroll-snap-type: y proximity !important;
        scroll-behavior: smooth !important;
    }
    
    article {
        scroll-snap-align: start !important;
        scroll-margin-top: 53px !important;
    }
    </style>
    `);
    
  3. Scroll to a tweet that contains an image or video

  4. Two-finger double tap on image/video to zoom in

Firefox will correctly zoom in on the image/video but then immediately scroll up and left by some small amount.

If I remove scroll-behavior: smooth, the issue no longer occurs.

Flags: qe-verify+

Reproduced the issue on Firefox 104.0a1 under macOS 13 by following the STR from Comment 8.

The issue is fixed on Firefox 104.0 on the same machine.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: