Open Bug 1541361 Opened 7 months ago Updated 4 months ago

The scroll is performed really slow on https://lab.hakim.se/monocle/

Categories

(Web Compatibility :: Desktop, defect, P3, minor)

Tracking

(firefox66 affected, firefox67 affected, firefox68 affected)

Tracking Status
firefox66 --- affected
firefox67 --- affected
firefox68 --- affected

People

(Reporter: oana.botisan, Assigned: miketaylr)

Details

(Keywords: webcompat:site-wait)

Attachments

(2 files, 1 obsolete file)

Affected versions

  • Firefox 68.0a1
  • Firefox 67.0b7
  • Firefox 66.0.2

Affected platforms

  • macOS 10.14
  • Windows 10 x64
  • Ubuntu 18.04 x64

Steps to reproduce

  1. Go to https://lab.hakim.se/monocle/.
  2. Scroll on the page.

Expected result

  • The scroll has a normal speed.

Actual result

  • The scroll is performed really slow.

Regression range

  • This might not be a regression, I can reproduce the issue on Nightly from 2017-01-02. I will try to find more information as soon as possible.

Additional notes

  • On Chrome the scroll is acting normally.

The page appears to be reimplementing scrolling by hijacking wheel scroll events and updating the transform property on the scroller element, so it's not really doing APZ scrolling.

Has Regression Range: --- → no

I don't think this is a regression. I can reproduce the issue using a build from 2012-01-02 and before that the site doesn't respond as it should.

Has Regression Range: no → ---
Has STR: --- → yes

I think the best we can do here is make sure the main thread is running at 60fps so that the reimplemented scrolling works well. Oana, can you get a gecko performance profile while scrolling on this page? On my macOS I'm getting pretty smooth scrolling.

Flags: needinfo?(oana.botisan)

I installed the Gecko Profiler and capture this profile. If it's not helpful please tell me so I can get you the information you need.

Flags: needinfo?(oana.botisan)

As far as I can tell from this profile everything is working perfectly. The wheel events get delivered the content main thread; on the next vsync tick content does a paint and sends it to the compositor; on the following vsync tick the compositor composites and everything finishes in time. There's a 2-3 frame latency between the wheel event and the screen refresh but that's expected in this case.

Can you describe what you mean by the scroll is "slow"? Do you mean that it just scrolls fewer pixels than on other pages? Or that there's an abnormally long delay between rolling the mousewheel and the page moving on-screen? Or maybe the scroll animation itself is slow (i.e. the page has a lower velocity when moving)?

Flags: needinfo?(oana.botisan)
Attached image safe browing not triggered.gif (obsolete) —

Please look at the attached gif, because it's much easier to see the difference. I scroll the same on both sites. In the first one, the scroll is really slow and on the second site, the speed of the scroll is normal.

Flags: needinfo?(oana.botisan)
Attachment #9057519 - Attachment is obsolete: true
Attached image slow scroll.gif

Please look at the attached gif, because it's much easier to see the difference. I scroll the same on both sites. In the first one, the scroll is really slow and on the second site, the speed of the scroll is normal.

Sorry for the spam. I attached the wrong gif the first time.

What input method are you using to scroll? Mousewheel? or trackpad? Or something else? And in comment 0 you said you see this on all platforms (Mac/Linux/Windows) - what input method were you using on Mac?

^

Flags: needinfo?(oana.botisan)

I researched this issue a bit and this is what I found out:

  • On mac:
    - using mouse: the bug is reproducing
    - using touchpad: the bug is not reproducing

  • On Windows:
    - using mouse: the bug is reproducing
    - using touchpad: the bug is reproducing

Flags: needinfo?(oana.botisan)

The page in question is reading the deltaY property from the wheel event without also checking the deltaMode. The deltaMode indicates that the wheel event is in "lines" but the page is scrolling by pixels. So it's a bug in the webpage implementation.

https://github.com/hakimel/css/blob/2cf77d34174a1375d6e16e532351efd97e0de226/monocle/iscroll-probe.js#L1067 should be checking deltaMode too and adjusting accordingly.

Component: Panning and Zooming → Desktop
Priority: P3 → --
Product: Core → Web Compatibility

This demo is a few years old, and unfortunately the author has disabled issues on the repo. (You can send in a PR, but the 4 sitting there don't seem to justify the energy to spin one up).

I'll send an email to the author.

Assignee: nobody → miket
Priority: -- → P3

Got a response from the author,

Thanks for letting me know. That demo uses a third party library called iScroll, which is no longer maintained. The mouse wheel error is inside of library code but should be fixable. I haven't touched this project in a few years now but will see if I can find time to look into it.

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