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•10 months ago
|
||
I'd say the scale value should be 1.0.
Does the site work fine before bug 1598145?
Set release status flags based on info from the regressing bug 1598145
Updated•10 months ago
|
Assignee | ||
Updated•10 months ago
|
Updated•9 months ago
|
Assignee | ||
Comment 3•9 months 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•9 months 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•9 months ago
|
Pushed by bwerth@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0143fd91ba20 Allow initial-scale clamping when user-scalable=no, add WPT. r=hiro
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/23713 for changes under testing/web-platform/tests
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Comment 8•9 months ago
|
||
bugherder |
Upstream PR merged by moz-wptsync-bot
Comment 10•9 months 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•9 months 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•9 months ago
|
Comment 12•9 months 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•9 months 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•9 months ago
|
||
bugherderuplift |
Comment 15•9 months ago
|
||
Thank you Brad and Emily!
Comment 16•9 months ago
|
||
Verified as fixed on the reported website, on Fenix Beta 5.1-beta2.
Description
•