1776598 - can't scroll page neither with mouse nor with arrow keys nor the scollbar is visible

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[bugra]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0

Steps to reproduce:

open page https://www.azurecitadel.com/ai/
the scrollbar is not visible, nor can the page be scrolled with arrow keys or mouse wheel

however page scrolling works on Chromium

Actual results:

can't scroll the page

Expected results:

should be able to scroll the page

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Panning and Zooming' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Timothy Nikkel (:tnikkel)]

There's a div

<div class="d-flex flex-column width-full overflow-y-auto" style="height:-webkit-fill-available">

which gets sized to fit all of the containing content in Firefox, but in Chrome it is sized to the visible area. Changing height to some fixed value "fixes" the problem, so seems to be some difference in flex box layout maybe?

Comment 3

[Emilio Cobos Álvarez (:emilio)]

So we don't support -webkit-fill-available, that's an issue. But even then when using -moz-available the behavior is not quite what the site expects. We treat these sizes as "auto" in the block axis, mostly because the wording in:

https://drafts.csswg.org/css-sizing-3/#sizing-values:

Which has a bunch of:

for a box’s block size, unless otherwise specified, this is equivalent to its automatic size.

Chrome seems to mostly behave similar in my attempt at a reduced test-case, so probably we need to reduce the page a bit more.

Comment 4

[David Shin[:dshin]]

Attachment: overflow-hidden.png

main content box div has overflow: hidden; set and disabling that seems to enable scrolling (As a workaround)

Comment 5

[David Shin[:dshin]]

Attachment: Mimimum Reproducible Case

Comment 6

[David Shin[:dshin]]

Attachment: Mimimum Reproducible Case, Fixed

(Fixed comments, was outdated).

Comment 7

[Daniel Holbert [:dholbert] (vacation until Jun 23)]

This feels S3-ish, given that the site is only using a webkit-prefixed sizing keyword, in a situation where they've clipping with overflow:hidden and hence have a strong dependency on a particular sizing behavior.

(Having said that, I'll take a look into the attached testcase that that demonstrates the difference with -moz-available though...)

Comment 8

[Daniel Holbert [:dholbert] (vacation until Jun 23)]

So the site renders in quirks mode since it's missing a doctype.

And it seems to have a fragile dependency on a quirks-mode-specific behavior of height:-webkit-fill-available, where (in webkit-based browsers) it appears to resolve to the available height in the viewport (or something like that). We don't have that quirks-mode behavior in Firefox with the equivalent -moz-available keyword (not that it matters too much for the original site since they're only specifying a -webkit keyword without specifying the -moz keyword). As emilio noted in comment 3, we're doing what the spec requires there (for the unprefixed keyword that we & Chrome are essentially implementing with these keywords).

The element that matters here is main which is one of the divs that this site styles with height:-webkit-fill-available, and that limits its height to fit the viewport, which gives its scrollable descendant some room to scroll.

I think the site could get the same effect by just specifying height:100% or height:100vh on this element instead of -webkit-fill-available.

Reclassifying as WebCompat, since there's not a Firefox bug here; this is a case of a site depending on a WebKit-specific quirks mode behavior in a WebKit-specific CSS keyword.

Comment 9

[Daniel Holbert [:dholbert] (vacation until Jun 23)]

Attachment: testcase 2 (even more reduced)

Here's a more-reduced testcase to illustrate Chrome's quirks-mode behavior here that the site is depending on here.

In this testcase, the black-bordered box is very tall in Firefox (shrinkwrapping its contents' height) vs. only the height of the viewport in Chrome.

Comment 10

[Daniel Holbert [:dholbert] (vacation until Jun 23)]

Attachment: testcase 3 (same as 2 but with a doctype to get standards-mode; Chrome agrees with Firefox here)

Here's the same testcase again but now with <!DOCTYPE html> to get standards-mode. This is sufficient to make Chrome change their behavior and match Firefox (rendering the black-bordered box super-tall).

This illustrates that the Chrome behavior in testcase 2 is just a quirks-mode thing (which the site happens to be depending on, probably by accident).

Comment 11

[Daniel Holbert [:dholbert] (vacation until Jun 23)]

Looks like the site's code is managed at https://github.com/azurecitadel/azurecitadel/ and https://github.com/azurecitadel/azurecitadel/issues/104 is already filed on this issue (by the same reporter I think?)

I'll add a few comments over there.

Comment 12

[Calin Tanase]

I was able to scroll using the mouse wheel. The scrollbar is visible while moving the cursor on the page, it fades after a few seconds of inactivity.

The scrollbar looks different on Chrome and it does not hide/fade after inactivity. Daniel, should we keep the report open?

Tested on:
Operating system: Ubuntu 22.04 LTS
Browser/version: Nightly 111.0a1 (2023-02-02) / Chrome 109.0.5414.119

Comment 13

[Daniel Holbert [:dholbert] (vacation until Jun 23)]

Yup, the site fixed the issue here, per https://github.com/azurecitadel/azurecitadel/issues/104#issuecomment-1377608467 .

We can close this. Thanks!

Comment 14

[Daniel Holbert [:dholbert] (vacation until Jun 23)]

(Specifically, they fixed it by adding height: 100% to the main element, per comment 8 -- I just confirmed that that's there now, using devtools.)