Closed Bug 1476995 Opened 6 years ago Closed 6 years ago

page with two different <meta name="viewport">s has a different "default width" on Chrome and Firefox on Android.

Categories

(Core :: Layout, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
mozilla64
Tracking Status
firefox63 --- wontfix
firefox64 --- fixed

People

(Reporter: twisniewski, Assigned: botond)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

In Firefox for Android, the devtools are reporting a default width of 980px for the HTML element on a completely blank page (on my Galaxy S7 Edge); in Chrome Mobile, it's 360px:

> <!DOCTYPE html><html></html>

Thus, if a page provides a typical meta-viewport tag to scale to the device-width (width=max-device-width, initial-scale=1), Firefox will zoom in on the content, likely leaving much of it off-screen.

If the page also specifies user-scalable=0, it will therefore be impossible for the user to pan around.

I'm not 100% sure if this is ultimately the same issue as bug 1423013 or bug 1423709, so I opted to file a new bug in case there really is some kind of "default width" we could tweak to eliminate viewport interop issues more quickly than more involved fixes.
Actually, the user-scalable=0 bit seems to be a separate issue, for which I've filed bug 1477007.
(In reply to twisniewski from comment #0)
> In Firefox for Android, the devtools are reporting a default width of 980px
> for the HTML element on a completely blank page (on my Galaxy S7 Edge); in
> Chrome Mobile, it's 360px:
> 
> > <!DOCTYPE html><html></html>

That's the case if the page does not have a meta-viewport tag.

Once you add a meta-viewport tag, the default width should be the width from the meta-viewport tag. On my Z3C device, it's 360px as well.

The page in the linked webcompat issue has a meta-viewport tag with "width=device-width". So, while there may be an inconsistency between Firefox and Chrome in how they size the page in the *absence* of a meta-viewport tag, that's not the cause of this webcompat issue (where the page *has* such a tag).
(In reply to Botond Ballo [:botond] from comment #2)
> The page in the linked webcompat issue has a meta-viewport tag with
> "width=device-width".

On second look, the page has a second meta-viewport tag with "width=max-device-width".

I haven't seen that before; it's not one of the special values documented on this page [1]. Looking at our code for parsing meta-viewport tags, it's not a value we recognize. That may be the problem.

Do you know of some documentation about the intended interpretation of width=max-device-width?

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag
Flags: needinfo?(twisniewski)
I think max-device-width is for media queries, not meta-viewport?

I'll take another look at this ASAP.

Regardless, the interop difference is still there, even if it ends up not affecting this site or being related to meta-viewport itself (Chrome still picks a different default width in this case).
The page's two <meta name="viewport">s are:

		<meta name="viewport" content="width=device-width">
		<meta name="viewport" content="width=max-device-width, initial-scale=1, minimum-scale=1, maximum-scale=1, user-scalable=0, minimal-ui"/>
Summary: HTML element has a different "default width" on Chrome and Firefox on Android. → page with two different <meta name="viewport">s has a different "default width" on Chrome and Firefox on Android.
Priority: -- → P3
I've just re-tested the live page, and the problem does indeed seem to be caused by the "max-device-width" value. If I change it to just "device-width", then Firefox scales the page as Chrome does, as expected. Likewise it also matches if I change the order of the meta tags thusly:

> <meta name="viewport" content="width=max-device-width, initial-scale=1, minimum-scale=1, maximum-scale=1, user-scalable=0, minimal-ui"/>
> <meta name="viewport" content="width=device-width">

In the above case, Firefox will take all of the values from the first meta tag, but then over-ride width to device-width from the second tag. The initial-scale and other properties carry over from the first tag. So it appears that unknown/invalid values aren't ignored outright, but rather reset the value to some fallback value.

However, based on Chrome's devtools, it looks as though width=max-device-width is being treated as width=device-width by Chrome, as is any other unknown/invalid value. Their source corroborates that:

>https://github.com/chromium/chromium/blob/4ba72f1b04fa80590ed084b29e5247906e87cdc9/third_party/blink/renderer/core/html/html_meta_element.cc#L178

So this would appear to be a case of differing fallback values for the width property for unknown values.

I'm not immediately sure what the difference is based on a quick glance at nsIDocument::GetViewportInfo(), though.
Flags: needinfo?(twisniewski) → needinfo?(botond)
(In reply to Thomas Wisniewski [:twisniewski] from comment #6)
> However, based on Chrome's devtools, it looks as though
> width=max-device-width is being treated as width=device-width by Chrome, as
> is any other unknown/invalid value. [...]
> 
> So this would appear to be a case of differing fallback values for the width
> property for unknown values.
> 
> I'm not immediately sure what the difference is based on a quick glance at
> nsIDocument::GetViewportInfo(), though.

We only size the viewport based on the display size if mAutoSize is set [1]. mAutoSize is only set if width=device-width was specified [2], or if no width was specified and either height=device-height or initial-scale=1 was specified [3].

It should be straightforward enough to modify the behaviour here to use device-width as the fallback in case of an unknown value, if that matches the behaviour of other browsers.

[1] https://searchfox.org/mozilla-central/rev/6c82481caa506a240a626bb44a2b8cbe0eedb3a0/dom/base/nsDocument.cpp#7381
[2] https://searchfox.org/mozilla-central/rev/6c82481caa506a240a626bb44a2b8cbe0eedb3a0/dom/base/nsDocument.cpp#7295
[3] https://searchfox.org/mozilla-central/rev/6c82481caa506a240a626bb44a2b8cbe0eedb3a0/dom/base/nsDocument.cpp#7302
Assignee: nobody → botond
Flags: needinfo?(botond)
Comment on attachment 9010032 [details]
Bug 1476995 - Use device-width as the fallback for unrecognized width values in a meta viewport tag. r?mstange

Markus Stange [:mstange] has approved the revision.
Attachment #9010032 - Flags: review+
Pushed by bballo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0c5229bcdc15
Use device-width as the fallback for unrecognized width values in a meta viewport tag. r=mstange
https://hg.mozilla.org/mozilla-central/rev/0c5229bcdc15
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Is this worth uplifting to beta63?
Flags: needinfo?(botond)
I'm not sure if it is, jcristau. I'd feel more comfortable giving it a cycle to bake, just in case there are other issues this uncovers (that and I'm not sure if it has made it to a nightly build yet, so I can't confirm if it's actually working).
Thanks.  We can let it bake in 64.
Flags: needinfo?(botond)
+1 for letting this ride the trains.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: