1830981 - pull to refresh: on dailymail.co.uk not working, either hides or forces address bar

Status: RESOLVED INVALID

(Core :: Panning and Zooming, defect, P3)

Description

[killercontact1.7.4.0]

Steps to reproduce:

Pull to refresh is not available on dailymail.co.uk, and the address bar either always in view, or is not in view at all, similar to PWA mode, which it is actually not. Using NIghtly as of May 2 (Build 2015948227) on Android 13 with Samsung

Expected results:

Normal fuction

Comment 1

[killercontact1.7.4.0]

Attachment: PTR dailymail.co.uk address bar remains hidden

Comment 2

[killercontact1.7.4.0]

Attachment: PTR dailymail.co.uk address bar stuck, PTR not working

Comment 3

[miralobontiu]

I was able to reproduce this issue on the latest Fenix versions: Nightly 118.0a1 from 8/22, RC 117.0, and Beta 117.0b9 with the following devices:

• Google Pixel 6 (Android 14), and
• Samsung Galaxy Note 8 (Android 9).

I'll confirm this ticket.

Comment 4

[Botond Ballo [:botond]]

I can reproduce this, but I'm seeing this behaviour in Chrome as well, which suggests to me that this is an issue with the site.

killercontact, could you confirm please that you see the issue in Chrome as well?

Comment 5

[killercontact1.7.4.0]

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

I can reproduce this, but I'm seeing this behaviour in Chrome as well, which suggests to me that this is an issue with the site.

killercontact, could you confirm please that you see the issue in Chrome as well?

Sorry I tested it against DDG browser with 106.0.5249126 webview and I could not reproduce. Chrome I cannot install on my device. Both behaviors aer still replicable with Nightly.

Comment 6

[Botond Ballo [:botond]]

I tried the DDG browser, and it looks like its address bar is not dynamic at all (i.e. it never hides in general, not just on this page).

I do see that pull-to-refresh works on dailymail.co.uk in the DDG browser, while not working in Firefox or Chrome. I'm not sure what would give rise to the behaviour difference between Chrome and DDG (which I believe also uses the Chromium engine); I think Chromium developers would be in a better position to investigate that.

Comment 7

[Botond Ballo [:botond]]

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

I do see that pull-to-refresh works on dailymail.co.uk in the DDG browser, while not working in Firefox or Chrome. I'm not sure what would give rise to the behaviour difference between Chrome and DDG (which I believe also uses the Chromium engine); I think Chromium developers would be in a better position to investigate that.

I filed an issue in the Chromium bug tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=1486712, hopefully the Chromium devs can provide some insight there.

Comment 8

[Botond Ballo [:botond]]

Anyways, I'm going to move this bug to the APZ component because the application layer is not doing anything wrong here: APZ is providing the InputResult value of HANDLED_CONTENT, and the application accordingly does not activate pull-to-refresh.

The part that remains to be investigated is whether that HANDLED_CONTENT value is correct (suggesting a site issue) or not (suggesting an APZ issue).

Comment 9

[Botond Ballo [:botond]]

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

The part that remains to be investigated is whether that HANDLED_CONTENT value is correct (suggesting a site issue) or not (suggesting an APZ issue).

The page has the following style rule:

html, body {
  overscroll-behavior-y: contain;
}

Per spec (see this example in particular), this is supposed to disable pull-to-refresh, and it successfully does so in Firefox and Chrome, but not in the DuckDuckGo browser.

Therefore, this bug is invalid; the DuckDuckGo browser is behaving in a non-standard way.

If you'd like the site to properly support pull-to-refresh, please contact the site authors and ask them not to opt out of pull-to-refresh with overscroll-behavior-y: contain.

Comment 10

[killercontact1.7.4.0]

Hello, thank you for contribution of the explanation.

I remain unsure why the toolbar at the bottom will not hide while scrolling, no matter being disabled.

Comment 11

[Botond Ballo [:botond]]

(In reply to killercontact1.7.4.0 from comment #10)

I remain unsure why the toolbar at the bottom will not hide while scrolling, no matter being disabled.

In Firefox, we have only implemented "scroll to hide toolbar" for the root scrollable element (<html> element) of a page. On the Daily Mail website, the scrollable content is inside a different element (a scrollable <div>) on the page. See also bug 1809173 where the same limitation means "scroll to hide toolbar" is not activated in our PDF viewer.