Closed Bug 1842690 Opened 1 year ago Closed 8 months ago

Trying to scroll up reloads the page on kucharkaprodceru.cz with pull-to-refresh enabled

Categories

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

Product:
Web Compatibility
Component:
Site Reports
Version:
Firefox 115
Platform:
All
Android
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: ksenia, Unassigned)

References

(
URL
)

Details

(Keywords: webcompat:sitepatch-applied)

Steps to reproduce

  1. With pull-to-refresh enabled visit https://www.kucharkaprodceru.cz/snehova-rolada/#more-13825 and scroll down.
  2. Scroll up.

Expected behavior

Scrolling up should work as expected

Actual behavior

Pull-to-refresh is triggered and page reloads

Device information

  • Firefox version: 117.0a1
  • Android device model: Pixel 4a
  • Android OS version: 13

Initially reported in https://github.com/webcompat/web-bugs/issues/123452

Confirmed.

This one looks like an issue on the APZ side: the InputResult value we're computing is Unhandled, which is incorrect.

Severity: -- → S2
Component: Browser Engine → Panning and Zooming
Priority: -- → P2
Product: Fenix → Core

This site is doing something fairly unusual:

  • The <body> element is overflow-y:hidden, so as far as APZ is concerned the page is not scrollable (this is why the InputResult value is not Handled).
  • The page listens for touch events and performs scrolling in the event listener (this is why the page appears scrollable in spite of being overflow-y:hidden.
  • However, the event listener does not preventDefault() the touch events (this is why the InputResult value is not HandledByContent).
    • It gets away with that because the page being overflow-y:hidden means that the browser default behaviour for the touch events is a no-op.

It's not clear what we can do about this in APZ. A passive touch event listener could just be observing touch events and not scrolling the page, so we don't want to return HandledByContent for pages with passive touch event listeners in general.

Interestingly, in Chrome the page does not appear to be overflow-y:hidden, and accordingly pull-to-refresh behaves as expected.

Confirmed via devtools that the page is not overflow-y:hidden in Chrome, meaning the site serves different content (or content with script that sets up different styles) to Chrome vs. Firefox.

After further investigation I have discovered the following:

  • The overflow-y:hidden style is set from script that appears to be a minified version of jquery.nicescroll, a jquery plugin whose purpose seems to be to customize the appearance of scrollbars and perform other scrolling customizations
  • The version of jquery.nicescroll the site appears to be using is 3.4.0, which is 10 years old
  • The logic to set overflow-y:hidden is in a branch that's conditioned on a variable cap.cantouch which is true in Chrome but false in Firefox (note: I'm linking to the corresponding non-minified source of version 3.4.0 for readability).
  • The relevant logic for setting cap.cantouch in turn looks like this: 
    //## Check Chrome desktop with touch support
    if (cap.cantouch&&cap.ischrome&&!cap.isios&&!cap.isandroid) {
      this.istouchcapable = true;
      cap.cantouch = false;  // parse normal desktop events
    }    

//## Firefox 18 nightly build (desktop) false positive (or desktop with touch support)
    if (cap.cantouch&&cap.ismozilla&&!cap.isios) {
      this.istouchcapable = true;
      cap.cantouch = false;  // parse normal desktop events
    }
    Note the Chrome block has a check for Android but the Firefox block does not; the code does not seem to consider Firefox for Android at all.

I created a minimal page using jquery.nicescroll 3.4.0, and the issue reproduces there.

I then made a modified version of the page which uses the latest version of jquery.nicescroll, 3.7.6, and the issue no longer occurs there. This version makes the page overflow:hidden in both Firefox and Chrome, but now the event listener is active and calls preventDefault(), so the InputResult is HandledByContent.

Given that, I'm leaning towards the resolution that we should reach out to the site author and encourage them to upgrade to a version of jquery.nicescroll that's newer than the 10-year-old version they're currently using which does not work well in Firefox for Android.

Thanks for the analysis, Botond!

We have a lot of issues with jquery nicescroll in Firefox on Android reported in https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+nicescroll and indeed upgrading to the newer version usually fixes the problem.

I'll contact the site owner to see if they can upgrade and we can also ship a sitepatch in the meantime.

Component: Panning and Zooming → Mobile
Flags: needinfo?(kberezina)
Product: Core → Web Compatibility
Version: Firefox 117 → Firefox 115
Depends on: 1849388

I think we can close this as it's fixed by the intervention in bug1849388

Status: NEW → RESOLVED
Closed: 8 months ago
Flags: needinfo?(kberezina)
Keywords: webcompat:sitepatch-applied
Resolution: --- → FIXED

I was not able to reproduce this issue neither on Fenix Nightly 124.0a1 builds from 1/31, and 2/1.
Tested with the following devices:

  • Google Pixel 6 (Android 14),
  • Lenovo tablet M10 (Android 10), and
  • Samsung Galaxy A14 (Android 13).
Component: Mobile → Site Reports
You need to log in before you can comment on or make changes to this bug.