Closed Bug 1709582 Opened 3 years ago Closed 1 year ago

[Proton] The overscroll bouncing effect is shaky when scrolling over the category bar on youtube.com

Categories

(Core :: Panning and Zooming, defect)

Desktop
macOS
defect

Tracking

()

RESOLVED DUPLICATE of bug 1760368
Tracking Status
firefox88 --- disabled
firefox89 --- affected
firefox90 --- affected

People

(Reporter: andrei.purice, Unassigned)

References

(Blocks 3 open bugs)

Details

(Whiteboard: [mac:ux] )

Affected Versions:
Nightly 90.0a1
Beta 89.0b8

Tested On:
MacOS 11.2.1 and 11.0.1

Steps to Reproduce:

  1. Reach https://youtube.com .
  2. Point the cursor under the site's categories recommendations.
  3. Start scrolling in order to achieve the overscroll effect.

Expected Results:
The overscroll effect is done without issues and the page bounces to normal state when stopped/interrupted.

Actual Result:
The overscroll bouncing effect is shaky.

Not reproducible on Safari nor Chrome.

Severity Suggestion:
QA suggests a severity of S2 for this issue since as Pascal said in https://bugzilla.mozilla.org/show_bug.cgi?id=1707217#c19 this site is a major site where issues like this one can be observed again and again.

Notes:
We will monitor other sites as well and complete the list here or file a new bug if more issues surface.
This seems to be a regression introduced by the fix https://hg.mozilla.org/releases/mozilla-beta/rev/3c232ce53c83 introduced for bug https://bugzilla.mozilla.org/show_bug.cgi?id=1707217 .

Video link: : https://drive.google.com/file/d/1HdNDU9vAtrhn-2SmSG5lHsmSNa4fcws7/view?usp=sharing

Hey Pascal,
Can you take a look over this issue since it could be a regression of bug 1707217?

Flags: needinfo?(pchevrel)
No longer blocks: overscroll-release
Flags: needinfo?(pchevrel)

(In reply to Andrei Purice from comment #0)

Video link: : https://drive.google.com/file/d/1TWN5cth5p94MvHt-qL_u61DK6f9Ap-WF/view?usp=sharing

This seems to be the incorrect video.

Sorry. This is the one : https://drive.google.com/file/d/1HdNDU9vAtrhn-2SmSG5lHsmSNa4fcws7/view?usp=sharing . Edited it in the body as well.

This is a known consequence of the fix for bug 1707217, as described in bug 1707217 comment 15.

What happens is:

  • The cursor starts below the element with the wheel listener (the category bar)
  • User scrolls upwards --> the page goes into overscroll
  • The overscroll translates the page contents downwards, so the category bar is now under the cursor
  • Now the events go through the wheel listener which calls preventDefault()
  • The preventDefault() causes the overscroll to be stopped, so the page goes back to its original position

If the cursor starts close enough to the category bar (i.e. just underneath it) that the the distance from the cursor to the category bar is traversed multiple times in the same scroll gesture, then the above sequence can happen repeatedly, resulting in the observed "shake".

Unfortunately, we don't have a good idea for how to mitigate this scenario further. The reason the behaviour does not happen with Chrome and Safari is that they handle preventDefault() differently for touchpad scrolls (they only seem to respect it for listeners on the element that was under the cursor at the beginning of a gesture), as discussed in bug 1707217 comment 13. This difference is pre-existing, and concerns touchpad scrolls in general (not just overscroll). Changing our behaviour in this way is something we can explore, but it's potentially a risky change (as it affects non-overscroll scenarios), so it's not something we can realistically do quickly (i.e. blocking the release of overscroll).

See Also: → 1709374

Tentatively marking this as not blocking release.

If we feel the issue is noticeable enough that it should block release, we could explore something like a webcompat intervention to disable overscroll on Youtube.

Whiteboard: [mac:ux]

I'm going to reduce the severity of this bug to S3, mostly to get it off the triage dashboard.

We haven't heard user complaints about this over the course of the 89 release cycle, and we don't really have an idea for how to fix it other than deploying a webcompat intervention as discussed in comment 5, which is a high bar.

Severity: S2 → S3

(In reply to Botond Ballo [:botond] from comment #4)

Unfortunately, we don't have a good idea for how to mitigate this scenario further. The reason the behaviour does not happen with Chrome and Safari is that they handle preventDefault() differently for touchpad scrolls (they only seem to respect it for listeners on the element that was under the cursor at the beginning of a gesture), as discussed in bug 1707217 comment 13. This difference is pre-existing, and concerns touchpad scrolls in general (not just overscroll). Changing our behaviour in this way is something we can explore, but it's potentially a risky change (as it affects non-overscroll scenarios), so it's not something we can realistically do quickly (i.e. blocking the release of overscroll).

This difference in behaviour has come up in bug 1746967 as well.

See Also: → 1746967

The behavior specified in this comment is fixed by bug 1168182. However, this bug was actually first fixed by bug 1760368. The overscroll transform should only apply to elements below the category bar, so the category bar (part of the header) no longer participates in overscroll. Note that the header does still participate in overscroll for the current version of Safari that I tested, but Chrome has the same behavior as we do.

Marking this as a duplicate of bug 1760368, but per the comment linked earlier, this could also be a duplicate of bug 1168182.

Status: NEW → RESOLVED
Closed: 1 year ago
Duplicate of bug: 1760368
Resolution: --- → DUPLICATE

Wow thanks!

You need to log in before you can comment on or make changes to this bug.