device-width conflict values in between initial-scale and width
Categories
(Core :: Panning and Zooming, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox76 | --- | unaffected |
firefox77 | + | verified |
firefox78 | + | fixed |
People
(Reporter: karlcow, Assigned: bradwerth)
References
(Regression, )
Details
(Keywords: regression)
Attachments
(1 file)
47 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
There is a site with these values
<meta name="viewport"
content="initial-scale=device-width,
maximum-scale=1.0,
user-scalable=no,
width=device-width">
The site is hugely blown out.
The current specification says:
https://drafts.csswg.org/css-device-adapt/#min-scale-max-scale
device-width and device-height are translated to 10
so we end up with
<meta name="viewport"
content="initial-scale=10,
maximum-scale=1.0,
user-scalable=no,
width=device-width">
which should win?
- Chrome shows the site with
width=device-width
- Firefox shows the site x10 zoom
This is yet another edge case.
note: can be reproduced on rdm.
see details on https://webcompat.com/issues/52856
Comment 1•5 years ago
|
||
I'd say the scale value should be 1.0.
Does the site work fine before bug 1598145?
Updated•5 years ago
|
Comment 2•5 years ago
|
||
Set release status flags based on info from the regressing bug 1598145
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years ago
|
||
This is solvable by adding a clamp to the code introduced in Bug 1598145. I'll propose a patch with a fix and a web platform test.
Assignee | ||
Comment 4•5 years ago
|
||
This corrects the handling of user-scalable=no to first apply the clamping
of the initial-scale (whether specified or default) to the min and max scales.
Updated•5 years ago
|
Comment 8•5 years ago
|
||
bugherder |
Comment 10•5 years ago
|
||
Thanks to :hiro for bringing this to the attention of the Fenix team. Could we please request this be uplifted to 77 so that we can get this fix for the Fenix product market fit experiment?
Assignee | ||
Comment 11•5 years ago
|
||
Comment on attachment 9150299 [details]
Bug 1638773: Allow initial-scale clamping when user-scalable=no, add WPT.
Beta/Release Uplift Approval Request
- User impact if declined: Sites with meta viewport tags with user-scalable=no and very large or very small initial-scale will appear at unreadable sizes in GeckoView.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The code change only applies when user-scalable=no, which is an uncommon pattern and noted as bad practice (though permitted by spec).
- String changes made/needed:
Assignee | ||
Updated•5 years ago
|
Comment 12•5 years ago
|
||
Comment on attachment 9150299 [details]
Bug 1638773: Allow initial-scale clamping when user-scalable=no, add WPT.
Fixes an important mobile web compat issue affecting Fenix. Approved for 77.0b9.
Updated•5 years ago
|
Comment 13•5 years ago
|
||
Changing the priority to p1 as the bug is tracked by a release manager for the current beta.
See What Do You Triage for more information
Comment 14•5 years ago
|
||
bugherder uplift |
Comment 15•5 years ago
|
||
Thank you Brad and Emily!
Comment 16•5 years ago
|
||
Verified as fixed on the reported website, on Fenix Beta 5.1-beta2.
Description
•