1603794 - Layout difference between Firefox and Chrome on https://ereader.learning.amplify.com

Status: NEW

(Core :: Layout, defect, P3)

Description

[Mike Taylor [:miketaylr]]

Sorry I don't have a better title for this, please update it.

Originally filed at https://github.com/webcompat/web-bugs/issues/46408

The original bug describes a redirect that requires Chrome, but if you spoof as Chrome in Firefox, you end up with a busted layout (which maybe explains the redirect?).

https://codepen.io/miketaylr/pen/MWYjaEQ shows the issue: in Firefox, the "Student / Educator" buttons are below the viewport, but in Chrome they're visible and to the right.

The weird thing about https://bug1603794.bmoattachments.org/attachment.cgi?id=9115808 is if I shrink the viewport in Firefox until the media query kicks in, if I expand it again, I get the same results as Chrome.

Furthermore, in https://bug1603794.bmoattachments.org/attachment.cgi?id=9115809, Chrome and Firefox are consistent and the only difference is a margin: 0 style missing from the first.

Comment 1

[Mike Taylor [:miketaylr]]

Attachment: 46408.html

Comment 2

[Mike Taylor [:miketaylr]]

Attachment: 46408-no-margin-on-body.html

Comment 3

[Emilio Cobos Álvarez [:emilio]]

Hmm, viewport units and scrollbars, fun. So this depends on whether the browser initially assumes there are going to be scrollbars for the viewport or not.

Viewport units don't account for scrollbars per spec, so if you start layout assuming there is a scrollbar, then the right box overflows, and creates a scrollbar. If you start without a scrollbar, then the right box just fits, and there's no need to create one.

This can be fixed trivially with :root { overflow: hidden } (or scrollbar-width: none)...

Comment 4

[Mike Taylor [:miketaylr]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

This can be fixed trivially with :root { overflow: hidden } (or scrollbar-width: none)...

(Good to know, I've attempted outreach for this site to understand why they block us in the first place. Assuming they respond I'll pass this along)

Comment 5

[Emilio Cobos Álvarez [:emilio]]

Attachment: Test-case that I would've hoped to show the difference

Seems chrome agrees with us here... I think this is probably a Chrome bug then.

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Oh, it does show the difference, nvm.

This seems to be because we guess that there's going to be a vertical scrollbar for the root here, which causes the content to overflow... InInitialReflow() returns false because we unconditionally return false if we're the root (that's a bit weird).

Boris, you seem familiar with that bunch of conditions... Does it seem reasonable to get rid of it assuming there's no performance regression?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Sure; it's a performance optimization, so if there is no performance impact...

Do we still have the "get the state from global history" thing going on? Because if we do, it might affect repeated loads (like Talos), so we'd need to be a bit careful with testing this.

Comment 8

[James Graham [:jgraham]]

Note: this requires non-overlay scrollbars to reproduce.

Comment 9

[Ksenia Berezina [:ksenia]]

Two linked webcompat issues no longer showing unsupported message, unsetting webcompat priority