Open Bug 1896571 Opened 1 year ago Updated 4 months ago

gracobaby.ca - The user can't scroll in page

Categories

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

Product:
Web Compatibility
Component:
Site Reports
Version:
Firefox 127
Type:
defect

Tracking

(Webcompat Priority:P3, Webcompat Score:1, firefox127 affected)

Status:
ASSIGNED
Project Flags:
Webcompat Priority P3
Webcompat Score 1
Tracking Flags:
Tracking Status
firefox127 --- affected

People

(Reporter: railioaie, Assigned: twisniewski)

References

(Depends on 1 open bug,
URL
)

Details

(Keywords: webcompat:platform-bug, webcompat:site-report, webcompat:sitepatch-applied)

User Story

platform:android
impact:site-broken
configuration:general
affects:all
branch:release
user-impact-score:100

Attachments

(3 files)

14.05.2024_10.12.19_REC.mp4
1.20 MB, video/mp4
Details
Bug 1896571 - Add scrolling intervention for gracobaby.ca; r?ksenia
48 bytes, text/x-phabricator-request
Details | Review
testcase 1: expected to draw a blue border around the viewport
278 bytes, text/html
Details

Environment:
Operating System: Samsung A51 (Android 11) -1080 × 2400 pixels 20:9 aspect ratio (~405 ppi density)
Firefox version: Firefox Release 125.3.0( 2016017559-🦎125.0.3-20240425211020🦎)/ Firefox Nightly 127.0a1 (2016018767-🦎127.0a1-20240503220029🦎)

Preconditions:
Clean profile

Steps to reproduce:

  1. Navigate to: https://www.gracobaby.ca/en_CA/All%20In%20Ones/SAP_2184499.html
  2. Observe the page

Expected Behavior:
The page can be scrolled

Actual Behavior:
The user can't scroll in page

Notes:

  • ScreenRec attached
  • Reproducible on the latest build of Firefox Focus Nightly and Focus Release
  • Not reproducible on Chrome.
  • Reproducible regardless of settings of Enhanced Tracking Protection
Severity: -- → S2
User Story: (updated)
Priority: P3 → P2

Their <html> element has overflow:hidden, and this is their meta viewport:

<meta name="viewport" content="width=device-width, initial-scale=1">

If I remove the <meta> element in the remote devtools, or that overflow, then scrolling works for me on my phone.

:hiro, this seems similar to bug 1895994 to me. What do you think?

Flags: needinfo?(hikezoe.birchill)
Component: Site Reports → Layout: Scrolling and Overflow
Keywords: webcompat:site-report
Product: Web Compatibility → Core

Yeah, it looks similar, but I can't tell it's same since I have no idea how Chrome scrolls such kind of overflow:hidden contents, it might be caused by different issues. I am totally unsure.

Also I confirmed this bug can be observable on desktop firefox as well with narrow browser window width.

There's;

@media (max-width: 767.98px) {
  html {
    height: -webkit-fill-available;
    overflow: hidden;
  }
}
Flags: needinfo?(hikezoe.birchill)
OS: Android → All
Hardware: ARM64 → All

Ok, for now I think I might just add site-patches for each of these bugs, but it worries me that this combination of things isn't causing a problem in Chrome; it would be nice if they could spec out their behavior.

Depends on: 1872755
Depends on: 1886561
No longer depends on: 1872755

We just got a tip from Karl Dubost that the page also doesn't scroll on Safari if the height:-webkit-fill-available is removed, which also seems to be the case on Chrome. But -moz-available does not work, curiously enough. Karl also pointed me to the code in WebKit: https://searchfox.org/wubkat/source/Source/WebCore/rendering/RenderBox.cpp#3666-3669, in case it helps.

Also, it looks like Blink was moving to alias -webkit-fill-available as stretch, based on https://github.com/web-platform-tests/interop-2022-viewport/issues/18#issuecomment-1268722823

Assignee: nobody → twisniewski
Status: NEW → ASSIGNED
Keywords: leave-open
Pushed by twisniewski@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/09fc424d98ce Add scrolling intervention for gracobaby.ca; r=ksenia,webcompat-reviewers

(In reply to Thomas Wisniewski [:twisniewski] from comment #5)

We just got a tip from Karl Dubost that the page also doesn't scroll on Safari if the height:-webkit-fill-available is removed, which also seems to be the case on Chrome. But -moz-available does not work, curiously enough.

Yeah, height:-moz-available doesn't help here, because we don't support -moz-available in the block axis (the 'height' axis in this case); we just treat -moz-available as auto in that axis (which isn't the behavior that the site wants in this case).

That deficiency in -moz-available is covered by bug 527285, for what it's worth. But I plan to add -webkit-fill-available support without that limitation, as I've just posted in bug 1872755 comment 9 (and adjusted the scope of that bug slightly) so that would fix this.

The platform fix will be in bug 1872755, I think. I'll add back a dependency on that bug, since it should fix this.

In the meantime, I don't think we need to track this as an S2, since we've mitigated the problem in this specific case (thanks Tom!) and the remaining platform work is already tracked elsewhere. (Really this is probably a dupe of bug 1872755, but we could consider it a site-report bug or just not worry about it & validate/close once bug 1872755 lands.)

Severity: S2 → S3

Here's a sort-of testcase here to illustrate how -webkit-fill-available behaves differently from -moz-available (for now) on the root element, with CSS like what hiro quoted in comment 3.

Firefox renders this with the bottom-border not visible (you have to scroll to reach it).
Chromium/WebKit render this with the bottom-border being visible, at the bottom of the viewport.

This seems to be just a site report and not also the root cause issue, so moving components.

Component: Layout: Scrolling and Overflow → Site Reports
Product: Core → Web Compatibility
Webcompat Priority: --- → P3
Severity: S3 → S2
User Story: (updated)
Webcompat Score: --- → 5
Priority: P2 → P3
Webcompat Score: 5 → 2
Webcompat Score: 2 → 1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: