1564253 - Page is cut off on itcentralstation.com, some content is out of reach

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Botond Ballo [:botond]]

STR

1. Run Firefox for Android on a tablet
2. Switch to landscape orientation
3. Load https://www.itcentralstation.com/products/comparisons/opnsense_vs_pfsense

Expected results

Page content fits screen width. This is what happens on Chrome.

Actual results

Some page content is cut off, and cannot be scrolled to.

Comment 1

[Botond Ballo [:botond]]

As mentioned here, in portrait orientation, Chrome has the same problem as Firefox, and on a phone with "Desktop site" checked, Chrome has the same problem as Firefox in either orientation.

Comment 2

[Botond Ballo [:botond]]

The ICB width is 980px and the content width 990px, but there is clearly more than 10px of content cut off, so this is not a "content out of reach" issue in the sense of bug 1423013 and family.

Perhaps the extra content is in an overflow-x: hidden div, and Chrome sizes the page differently such that the div doesn't have overflowing content in Chrome?

Comment 3

[Botond Ballo [:botond]]

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

Perhaps the extra content is in an overflow-x: hidden div

Yes, that's exactly it: <div id="page"> has the width of the ICB (990px) and is overflow: hidden, and its child <div id="page-content"> has width 1300px.

Comment 4

[Botond Ballo [:botond]]

Whereas Chrome seems to size the ICB to 1280px, which is the width of my tablet in landscape mode. The content size also becomes 1280px (the 990px is a min-width), and the div only has 20px of overflow (not really noticeable).

The page does not have a meta viewport tag. So I guess this is a case of Chrome defaulting to width=device-width while we default to width=980px?

Comment 5

[Hiroyuki Ikezoe (:hiro)]

Probably this file is used on tablets?
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/viewportTelevision.css

Comment 6

[Botond Ballo [:botond]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #5)

Probably this file is used on tablets?
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/viewportTelevision.css

Hah! I assumed it was device-width because my tablet's width happens to be 1280px :) But you're right, it's more likely they're using a fallback value based on the form factor.

So the proposed solution is: change browser.viewport.desktopWidth (the fallback value) to 1280px on tablets?

Comment 7

[Hiroyuki Ikezoe (:hiro)]

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

(In reply to Hiroyuki Ikezoe (:hiro) from comment #5)

Probably this file is used on tablets?
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/viewportTelevision.css

Hah! I assumed it was device-width because my tablet's width happens to be 1280px :) But you're right, it's more likely they're using a fallback value based on the form factor.

So the proposed solution is: change browser.viewport.desktopWidth (the fallback value) to 1280px on tablets?

That's promising. Though I don't know where the tablet specific pref file is. :)

Comment 8

[Botond Ballo [:botond]]

Well, we already do some things differently on a tablet. For example, the browser UI looks different (e.g. the Reload button is directly on the screen rather than in the menu).

Jan, do you know where / how we detect that we're on a tablet for these purposes?

Comment 9

[Jan Henning [:JanH]]

Two possibilities:

1. We let the front end directly configure this pref (which for GeckoView means bug 1511177, or something like that), so on startup it could set a different value if running on a tablet/during full moon/whatever... For Fennec it might be possible to uplift the GeckoView settings API change to ESR as well and use that during startup, too, or just bypass GeckoView and use the existing code for manipulating Gecko preferences from Java code.
2. Use a second browser.viewport.desktopWidthTablet Gecko pref and let the Gecko code switch automatically between that and the original pref depending on the same property that the UA code also uses (and which ultimately leads back here).

Not sure which way would be preferable, though.

Comment 10

[Botond Ballo [:botond]]

I guess this is a GeckoView API design question.

Basically, we want to give tablets a wider fallback viewport (1280px instead of 980px) if there is no meta viewport tag specified. This could work in one of several ways:

• The determination "is this a tablet" is made by GeckoView (based on e.g. HardwareUtils.isTablet()), and applies to all embedders without giving them a chance to override.
• The determination "is this a tablet" is made by the embedder, and GeckoView provides an API to be told about it.
• A combination, e.g. GeckoView makes a default choice but embedders can override it.

:snorp, which of the above do you think is preferable?

Comment 11

[James Willcox (:snorp) ([e-mail]) (he/him)]

I prefer option 2), since that affords the most flexibility for the app. I think maybe we should just allow specifying an exact pixel value for the fallback viewport, with constants defined for the common values.

Comment 12

[Dennis Schubert [:denschub]]

The site in question has changed and no longer sees this issue, and from what I can tell, this doesn't look like a general or widespread issue. Closing for now, but we can always reopen.