Closed Bug 1336346 Opened 7 years ago Closed 7 years ago

[viewport] overflow is enforced even when the layout is larger than the viewable screen area

Categories

(Core :: Panning and Zooming, defect, P3)

Product:
Core
Component:
Panning and Zooming
Version:
54 Branch
Platform:
ARM
Android
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1123938
Tracking Flags:
Tracking Status
firefox54 --- affected

People

(Reporter: karlcow, Unassigned)

References

(
URL
)

Details

(Whiteboard: [webcompat][gfx-noted]) 

(change the product/component adequately if I missed something)

This issue is part of a couple of tests, I'm doing comparing Firefox Android
and Chrome Android for layout differences wrt viewport values.
The tests are available at http://la-grange.net/2016/12/01/viewport/

Test 0008 - <name="viewport" content="width=device-width, initial-scale=1.0">
            + body {overflow-x: hidden;}
http://la-grange.net/2016/12/01/viewport/viewport-test-0008.html


* Firefox and Chrome scales the page roughly the same. Yeah!
  The 700px image is overflowing in both cases.

* Firefox enforces the overflow-x and blocks the scrolling on the right side.
* Chrome ignores the overflow-x and gives the possibility to see the overflowing image.
URL: http://la-grange.net/2016/12/01/viewp...
Whiteboard: [webcompat]
Component: Graphics, Panning and Zooming → Panning and Zooming
OS: Unspecified → Android
Priority: -- → P3
Product: Firefox for Android → Core
Hardware: Unspecified → ARM
Whiteboard: [webcompat] → [webcompat][gfx-noted]
Blocks: 1336884
Another instance of the overflow hidden.
https://webcompat.com/issues/4005
See Also: → https://webcompat.com/issues/4005
https://webcompat.com/issues/4481

* Because the content is not being resized to the viewport like Chrome does ( Bug 1336332 )
* we get the issue of not being able to scroll because of overflow ( Bug 1336346 )

<meta name="viewport" content="width=device-width">

html, body, nav {
	width: 748px !important;
	overflow-x: hidden !important;
	position: relative;
}
See Also: → https://webcompat.com/issues/4481
https://webcompat.com/issues/4190

#main, header {
	width: 960px;
	position: relative;
	margin: 0 auto;
}

body {
	overflow-x: hidden;
}

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


Scrollable in Chrome, not in Firefox.
See Also: → https://webcompat.com/issues/4190
Ah! Thomas has filed an issue for Chrome on Android.
https://bugs.chromium.org/p/chromium/issues/detail?id=689630

I wonder if the Chromium project will decide to break the Web site currently working. That would be good if they could align with us.
More background about why Chrome is doing what it does:

https://bugs.chromium.org/p/chromium/issues/detail?id=689630#c6
> Chrome does honour the overflow: hidden property on 
> <html>/<body> but the behavior can be tricky to 
> understand in cases like this. What's going on:
> 
> -Because the content is wider than the viewport, 
> we expand the layout viewport to encompass the whole 
> content width. We need to do this so that the user 
> can zoom out to see the whole page.
> 
> -Because the layout viewport is expanded, it has 
> no scrolling. Layout viewport is the regular kind 
> of scrolling you'd see on a desktop or unzoomed 
> mobile site.
> 
> -What you're seeing is visual viewport panning 
> which doesn't respect the overflow property (since 
> it's panning within the layout viewport, not the 
> page content).
> 
> To see this more clearly, remove the initial-scale=1.0 
> attribute on the viewport meta. You'll now see that 
> the page is loaded zoomed out and you can't scroll 
> horizontally. What you're seeing with initial-scale 
> is as if you zoomed into an "unscrollable" page and 
> you can pan around. This is expected.
> 
> Authors can use minimum-scale=1 to cap the size of 
> the layout viewport so you'd get the expected behavior.
> 
> Interop regarding viewport meta is known to be painful 
> due to many quirks and different zoom implementation 
> between all the browsers. This might become more 
> tractable once Safari and Firefox ship a "virtual 
> viewport" model of pinch-zoom. 
> 

It gives us a bit more understanding on what is happening and how we could maybe converge on a solution for all mobile browsers.
Another site with an overflow-x: hidden
See Also: → https://webcompat.com/issues/4841
Flags: webcompat?
See Also: → https://webcompat.com/issues/6564
This is another variation of this issue. 
Google Chrome on mobile ignores the overflow set on the body aka `overflow: hidden`, it means that devices with smaller screens and Firefox can't access the full content of the splash screen, because it has been designed for a certain ratio.

See for details https://webcompat.com/issues/6497


I have the feeling it is a reasonable move from Google Chrome team. 
I'm curious where exactly in the Chromium code this is happening. 
I filed https://github.com/whatwg/compat/issues/79
See Also: → https://webcompat.com/issues/6497
Summary: [viewport] overflow-x is enforced even with an image overflowing → [viewport] overflow is enforced even when the layout is larger than the viewable screen area
I get slightly different CSS between my Nexus 5X and my Nexus 6 on Chrome Canary (60.0.3111.0): The 5X gets overflow: hidden and the dialog is unscrollable. The 6 does not and scrolling is possible. The page is adding a .modal-open class to the body Element which adds overflow: hidden. I'm guessing this is based on viewport size? In the case where it's added though, Chrome does respect it.
There is a very useful test about this
https://bokand.github.io/viewport/index.html

>  Firefox does not distinguish between the visual 
> and layout viewport. As the user pinch-zooms, 
> the layout viewport shrinks with the visual 
> viewport. The practical effect of this is that 
> position: fixed elements stick to the visual 
> viewport and there's no way to scroll them if 
> they overflow the visual viewport. 

And this issue is probably a duplicate of Bug 1123938

Daniel should we close this one and report the Web compat bugs there?
Flags: needinfo?(dholbert)
After reading again the Bug 1123938 let's go ahead. :)
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(dholbert)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.