1526940 - Viewport's width is larger than the available width at load time in a mobile site

Status: NEW

(Core :: Layout, defect, P3)

Description

[Julien Wajsberg [:julienw] (PTO -> Jul 24)]

Hi,

This is something I see often when reading news on lemonde.fr for some weeks now, happening on Android. I'm linking this to the fix in bug 1423013 but this is a wild guess.

When loading some of the news article (an example is [1]), there's a very slight difference between the device's width and the viewport's width, leading to the website being horizontally scrollable, which is a UX problem because scrolling horizontally blocks the vertical scroll when I trigger it by mistake.

From what I see, the images take the full viewport's width (which is expected from their width: 100%), but all the text + the footer's background extend only to the edge of the device's width. The footer especially is a "normal" block element so it should also normally extend to the full width.

So clearly there's something fishy happening.

Related or unrelated, the images lazy loading doesn't work properly, we need to scroll down during a long height below the image to make it load. Content images in this page use a <picture> container, maybe that's related.

Both these problems don't reproduce in devtools' responsive view.

[1] https://www.lemonde.fr/culture/article/2019/02/11/grammy-awards-2019-this-is-america-de-childish-gambino-elue-chanson-de-l-annee_5421811_3246.html

Comment 1

[Botond Ballo [:botond]]

I've seen this on a few websites as well, where the content is just ever so slightly horizontally scrollable. I wonder if there's a rounding error or something happening during minimum scale computation.

Comment 2

[Hiroyuki Ikezoe (:hiro)]

id=Header element in the site takes 374px width on 360px width device. And I can see a child element in the header has 'width: 100%' with 'padding: 1.2rem 0'.

Comment 3

[Hiroyuki Ikezoe (:hiro)]

This should be fixed by bug 1519013.

Comment 4

[Neha Kochar [:neha]]

Hiroyuki, per comment 3, should we dup this to bug 1519013?

Comment 5

[Botond Ballo [:botond]]

In cases like this, I think it's better to leave this open until bug 1519013 is fixed, then re-test the site in this bug. If the issue is indeed fixed, we can dup this to bug 1519013 at that point.

This way, in case bug 1519013 does not fix this issue after all, we don't forget about it.

Comment 6

[Hiroyuki Ikezoe (:hiro)]

I totally agree with Borond.

Comment 7

[Pascal Chevrel:pascalc]

This bug depends on bug 1519013 which depends on bug 1516056, which targets 68. We may evaluate uplifting targeted patches to fix this issue and bug 1519013 but given the multiple dependencies and the fact that we are now in beta for 67, I am marking this bug as fix-optional so as to remove it from our weekly regression triage.

Comment 8

[Hiroyuki Ikezoe (:hiro)]

I did confirm bug 1519013 didn't fix this at all. And now I noticed that Chrome Canary doesn't fit the content to screen either. :/ I don't know why yet.

Comment 9

[Botond Ballo [:botond]]

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

I've seen this on a few websites as well, where the content is just ever so slightly horizontally scrollable. I wonder if there's a rounding error or something happening during minimum scale computation.

It's possible that this has to do with the snapping issue described here.

Comment 10

[Julien Wajsberg [:julienw] (PTO -> Jul 24)]

I confirm this still happens in today's nightly of Fennec.

Comment 11

[Patricia Lawless]

Bulk change of P3 carryover bugs to wontfix for 68.

Comment 12

[Botond Ballo [:botond]]

This has started to affect Github pages such as https://github.com/mozilla-mobile and https://github.com/mozilla-mobile/focus-android/ sometime between 68 and 69.

Comment 13

[Botond Ballo [:botond]]

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

This has started to affect Github pages such as https://github.com/mozilla-mobile and https://github.com/mozilla-mobile/focus-android/ sometime between 68 and 69.

Note that this only happens with "Request desktop mode", even on a tablet where the server sends the same content with or without "Request desktop mode".