1438514 - [Youtube] Visual glitches are triggered by the scrolling attempt, when the "Share" window is opened

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P3)

Description

[Anca Soncutean, Desktop QA]

Attachment: screencast showing the issue.mkv

[Affected versions]: 
- 58.0.2 (20180206200532)
- 59.0b9 (20180209162511)
- 60.0a1 (20180214224814)

[Affected platforms]:
- Windows 10 x64
- Ubuntu 16.04 x64
- Mac Os x 10.11

[Steps to reproduce]:
1. Launch Firefox
2. Go to https://www.youtube.com/ and open a random video
3. Click on the Share button
4. Try to scroll using the scrollbar

[Expected result]:
- Nothing happens.

[Actual result]:
- Visual glitches are triggered by the scrolling attempt.

[Regression range]:
- Last good revision: 3119a9a0b5dee60ac77b7596ae5dbe0658f598ad (2016-12-27)
- First bad revision: d7b6af32811bddcec10a47d24bd455a1ec1836fc (2016-12-28)
- Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3119a9a0b5dee60ac77b7596ae5dbe0658f598ad&tochange=d7b6af32811bddcec10a47d24bd455a1ec1836fc

[Additional notes]:
- This behaviour is reproducible also, with the "Add to" and dropdown menu "..."  opened windows.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Botond, not sure if you have cycles to look into this. From the video this looks like a not-great experience.

Comment 2

[Botond Ballo [:botond]]

I can repro this, somewhat intermittently; it seems to help (to repro the issue) to perform the steps as quickly as possible after loading the page.

I can investigate.

Comment 3

[Botond Ballo [:botond]]

My suspicion is that we have a similar situation to bug 1365761 comment 4, where scroll offset updates from the main thread and scroll offset updates from APZ scrollbar dragging are stepping on each other's toes. I haven't confirmed that yet though.

Comment 4

[Botond Ballo [:botond]]

Here's what's producing the main thread scroll offset updates:

0 _restoreScrollPosition() ["https://www.youtube.com/yts/jsbin/desktop_polymer-vflrnseTy/desktop_polymer.js":3222]
    this = [object HTMLElement]
1 _onCaptureScroll([object UIEvent]) ["https://www.youtube.com/yts/jsbin/desktop_polymer-vflrnseTy/desktop_polymer.js":3220]
    this = [object HTMLElement]
2 _onCaptureScroll([object UIEvent]) ["self-hosted":996]
    this = [object HTMLDocument]

Comment 5

[Botond Ballo [:botond]]

Basically, when a "popup" (the little widget that comes up when one of the "Share", "...", etc. buttons is pressed) opens, the page saves the current scroll position, and installs a "scroll" event handler that resets the scroll position to the saved position on each event.

With main-thread scrolling, the scroll offset change triggered by the mousemove event that drags the scrollbar (which generates the "scroll" event) and the scroll offset change triggered by the page's scroll event handler are processed in sequence within a single refresh driver tick, so the user consistently sees only the end result (no scrolling).

With APZ scrolling, the scroll offset change triggered by the page's scroll event handler is sent to APZ and overrides APZ's scroll position based on dragging, but this doesn't happen consistently on every composited frame.

Basically, the page is using a "scroll-linked effect" to prevent scrolling while the popup is open, and it doesn't work great with APZ.

(The similarity to bug 1365761 comment 4 is superficial. There, the page was registering a mouse event handler, and the observed behaviour was an artifact of a subtle event ordering issue. Here, the page is registering a scroll event handler, and the observed behaviour is the well-known behaviour of a scroll-linked effect.)

Bug 1375949 (the APZ frame delay) helps, in that if the main thread can paint the page within the frame budget, the scroll offset update will reach the compositor in time to override the APZ scrolling. This is why the flicker of the scroll position is only intermittent, instead of happening practically all the time. (This can be seen by disabling "apz.frame_delay.enabled" and trying the STR: the flicker now happens much more often.)

In principle other APZ input methods are affected as well, not just scrollbar dragging, but e.g. for wheel scrolling, the page preventDefault()s wheel events while the popup is open, so the issue only occurs if the main thread is so slow that APZ doesn't get the preventDefault() message within the 400ms timeout. I don't believe there's a comparable way for the page to prevent scrollbar dragging via preventDefault().

Unfortunately, I don't have any great ideas for what we can do on our end to make the experience better here. I'm inclined to treat this issue as a Tech Evangelism issue, but I don't even know what better mechanism to suggest to the website authors to prevent scrolling while the popup is open, that would play nicely with APZ (short of making the page overflow:hidden, which presumably they don't want to do as it would hide the scrollbar and potentially confuse the user). Kats, Markus, any ideas?

Comment 6

[Markus Stange [:mstange]]

I don't think there is a way to express "keep the scrollbar visible but don't allow scrolling with it". I would suggest to YouTube that they simply let the user scroll normally... but there must be a reason why they implemented this functionality.

If the root scroller were implemented as a scrollable div, then you could disable mouse input to the scrollbar by covering the div with some transparent element. But doing that comes with other disadvantages.

I think what Firefox is doing here is reasonable, even if it's not the greatest experience in this particular case.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

+1 to what Markus said. I'd move this to Tech Evangelism or use the mozilla-google discuss list to find out if they can try other approaches to accomplishing their desired effect (or changing the behaviour to allow scrolling and avoid the glitching).

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Adam, can you please help with comment 7?

Comment 9

[Botond Ballo [:botond]]

Based on comment 6 and comment 7, moving to Tech Evangelism.

The suggested fix on the website's side is either:

  - make the page overflow:hidden while the popup is present,
    which will both prevent scrolling and hide the scrollbars; or

  - allow scrolling while the popup is present.

If there's an important reason for the current behaviour (preventing scrolling while the scrollbars are shown), we'd like to know, and can try to suggest other solutions.

Comment 10

[Mike Taylor [:miketaylr]]

Karl, can you get in touch with Youtube? Thanks!

Comment 11

[Karl Dubost💡 :karlcow]

Contacted today on the partner mailing-list.

Comment 12

[Julien Cristau [:jcristau]]

This is now tracked at https://github.com/PolymerElements/iron-overlay-behavior/issues/266

Comment 13

[Sergiu Logigan [:sergiu]]

Oana, can you please recheck this?

Looks like on Windows 10 and MacOS with Firefox Nightly 63 it does not reproduce.

Comment 14

[Oana Arbuzov [:oanaarbuzov]]

I've tested the issue and it seems to be fixed, no visual glitches were encountered.
Note that You Tube layout has also changed since the issue was reported.

[Tested with:]
Browser / Version: Firefox Nightly 63.0a1 (2018-08-09)
Operating System: Linux Ubuntu 16.04

@Anca Soncutean can you still reproduce it on any platform?

Comment 15

[Anca Soncutean, Desktop QA]

Indeed, I can’t  reproduce the issue anymore with the “Share” panel, but is still reproducible for me (intermittent) with the  "Add to" (only on Ubuntu 16.04 x64) and More action "..." (across all platforms : Windows 10 x64, macOS 10.13, Ubuntu 16.04x64)dropdowns. See screenshot with the issue - made on Windows 10 on the latest Nightly: https://drive.google.com/open?id=1AnPH2ZgM9XRqwBUf7TyN0JM5PsFC44uE .

Comment 16

[Alice0775 White]

(In reply to Anca Soncutean [:Anca], Desktop Release QA from comment #15)
> Indeed, I can’t  reproduce the issue anymore with the “Share” panel, but is
> still reproducible for me (intermittent) with the  "Add to" (only on Ubuntu
> 16.04 x64) and More action "..." (across all platforms : Windows 10 x64,
> macOS 10.13, Ubuntu 16.04x64)dropdowns. See screenshot with the issue - made
> on Windows 10 on the latest Nightly:
> https://drive.google.com/open?id=1AnPH2ZgM9XRqwBUf7TyN0JM5PsFC44uE .

Yep, I can also reproduce the issue on Windows10.

Comment 17

[Oana Arbuzov [:oanaarbuzov]]

Thanks Anca for further investigating the issue. I was able to reproduce the glitch on Windows 10 while "Add to" and "More action" menus are active.
Note: On Chrome while "Add to" and "More action" menus are active the page scroll is disabled.

[Tested with:]
Browser / Version: Firefox Nightly 63.0a1 (2018-08-09)
Operating System: Windows 10 Pro

Comment 18

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late to fix in 63, but we could still take a patch in 65 and potentially, 64 beta.

Comment 19

[Botond Ballo [:botond]]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #18)
> Too late to fix in 63, but we could still take a patch in 65 and
> potentially, 64 beta.

Note that as per comments 5-7, there isn't really a way that we can think of to fix this on the Firefox side. The fix will need to come from the site side.

Comment 20

[Alexandru Trif, Desktop QA [:atrif]]

I can confirm the issue is reproducible using any Youtube pop-up menu. I noticed that on Nightly 67.0a1 (20190128214724) and Firefox 66.0b3 (20190128143734). For more details see the following screencast https://drive.google.com/open?id=1xqtOdXuBU6VEuAisVp8-9IvqvpEpCFCj.

Comment 21

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Comment 22

[Raul Bucata]

I was not able to reproduce the issue. Scrolling the page following the steps to reproduce does not present any issues:

https://prnt.sc/AKP5ukuN6fs8

Anca, is the issue still reproducible on your side?

Tested with:

Browser / Version: Firefox Nightly 101.0a1 (2022-04-10) (64-bit)
Operating System: Windows 10 PRO x64

Comment 23

[Anca Soncutean, Desktop QA]

(In reply to raul softvision from comment #22)

I was not able to reproduce the issue. Scrolling the page following the steps to reproduce does not present any issues:
Anca, is the issue still reproducible on your side?

No, I confirm this issue is no longer reproducible on my side either with the latest Fx builds on Windows 10.

Comment 24

[Raul Bucata]

Thank you, for confirming.