Pages are zoomed in when there isn't enough vertical content to zoom them out
Categories
(Firefox for Android Graveyard :: General, defect, P3)
Tracking
(firefox-esr68 wontfix, firefox66 wontfix, firefox67 wontfix, firefox68 wontfix, firefox69 wontfix, firefox70 wontfix, firefox71 wontfix, firefox72 fixed)
People
(Reporter: csheany, Assigned: hiro)
References
Details
(Keywords: regression)
User Agent: Mozilla/5.0 (Android 7.1.1; Tablet; rv:66.0) Gecko/66.0 Firefox/66.0
Steps to reproduce:
- Open github.com/mozilla-mobile/focus-android
- Request desktop site
- Tap on Contributors
Actual results:
The page is zoomed in
Expected results:
The page should be zoomed out
Comment 1•6 years ago
|
||
Please try to post clickable links:
Comment 2•6 years ago
|
||
This is a combination of bug 1508177 and bug 1519013. Bug 1508177 is preventing the page from being zoomed out in its initial state, before the contributor data is loaded. Bug 1519013 is why we don't update the zoom automatically when the data does load.
Comment 3•6 years ago
|
||
Thanks for your report!
I was able to reproduce this with Samsung Galaxy Tab S3(Android 8.0) following the steps provided. Based on this and comment 2 I will set the bug as new.
Comment 4•6 years ago
|
||
So, now that bug 1519013 is fixed, the page does zoom out as soon as the contributors list is loaded.
While the list is loading, the page is still zoomed in; this is the part that will be fixed by bug 1508177.
Comment 5•5 years ago
|
||
Hi!
This is reproducible, as mentioned in Comment 4, on Beta 68.0b14, Nightly 68.0a1 (2019-06-28) with OnePlus 5T (Android 9).
Updated•5 years ago
|
Comment 6•5 years ago
|
||
The remaining bug here is specifically about cases where a page is zoomed in because there isn't enough content vertically to zoom them out further. I edited the bug title to reflect this.
https://webcompat.com/issues/32630 is a different issue; I'll file a new bug for it.
Comment 7•5 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #6)
https://webcompat.com/issues/32630 is a different issue; I'll file a new bug for it.
Filed bug 1564253, but please note that, as explained here, there appears to be a site issue there as well.
Comment 8•5 years ago
|
||
I actually don't see this anymore, even before the fix of bug 1508177, modulo the fact that the page is slightly horizontally scrollable, even before tapping on "Contributors" (which I think is bug 1526940).
Comment 9•5 years ago
|
||
The bug 1526940 behaviour was not present before, but is now, replacing the original bug here.
The behaviour seems to have changed sometime between 68 and 69. Unfortunately, due to bug 1573207, I'm not able to find a window for it.
Comment 10•5 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #8)
I actually don't see this anymore, even before the fix of bug 1508177, modulo the fact that the page is slightly horizontally scrollable, even before tapping on "Contributors" (which I think is bug 1526940).
(In reply to Botond Ballo [:botond] from comment #9)
The bug 1526940 behaviour was not present before, but is now, replacing the original bug here.
The behaviour seems to have changed sometime between 68 and 69. Unfortunately, due to bug 1573207, I'm not able to find a window for it.
I see now what was confusing me: on a tablet, even though the site sends the same content with or without "Request desktop mode", the behaviour is different. The "bug 1526940 behaviour" only occurs with "Request desktop mode", and the behaviour which is the subject of this bug only occurs without "Request desktop mode". The latter was indeed fixed by bug 1508177 as expected, although the change made in bug 1508177 is Nightly-only for now.
I'm going to update the dependency from bug 1508177 to bug 1571599, which tracks shipping the behaviour change on all channels.
Comment 11•5 years ago
|
||
Updating status flags, on the assumption that bug 1508177 isn't going to be uplifted anywhere.
Comment 12•5 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #9)
Unfortunately, due to bug 1573207, I'm not able to find a window for it.
By the way, for posterity, I did find a way to get regression windows for mobile platform regressions in the 68-70 range: since we still do Fennec builds from mozilla-central in that range, you can use mozregression
in that range if you specify --repo=mozilla-central
. The one minor caveat is that you have to specify the ends of the range as commit SHAs rather than dates or version numbers, but it's pretty easy to map dates or version numbers to commit SHAs (one way is to do a dummy mozregession
run with the default app (desktop firefox) with the dates or version numbers, and look at the pushlog it prints at the beginning).
Comment 13•5 years ago
|
||
I'm going to mark this as fixed as the dependent bugs have both landed now.
Comment 14•5 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
Updated•5 years ago
|
Updated•4 years ago
|
Description
•