Closed Bug 1523514 Opened 5 years ago Closed 5 years ago

Pages are zoomed in when there isn't enough vertical content to zoom them out

Categories

(Firefox for Android Graveyard :: General, defect, P3)

Firefox 66
ARM
Android
defect

Tracking

(firefox-esr68 wontfix, firefox66 wontfix, firefox67 wontfix, firefox68 wontfix, firefox69 wontfix, firefox70 wontfix, firefox71 wontfix, firefox72 fixed)

RESOLVED FIXED
Firefox 72
Tracking Status
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:

  1. Open github.com/mozilla-mobile/focus-android
  2. Request desktop site
  3. Tap on Contributors

Actual results:

The page is zoomed in

Expected results:

The page should be zoomed out

Please try to post clickable links:

https://github.com/mozilla-mobile/focus-android/

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.

Depends on: 1508177, 1519013

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.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3

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.

Hi!
This is reproducible, as mentioned in Comment 4, on Beta 68.0b14, Nightly 68.0a1 (2019-06-28) with OnePlus 5T (Android 9).

OS: Unspecified → Android
Hardware: Unspecified → ARM

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.

Summary: Pages are zoomed in upon loading → Pages are zoomed in when there isn't enough vertical content to zoom them out

(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.

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).

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.

(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.

Depends on: 1571599
No longer depends on: 1508177

Updating status flags, on the assumption that bug 1508177 isn't going to be uplifted anywhere.

(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).

I'm going to mark this as fixed as the dependent bugs have both landed now.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression
Assignee: nobody → hikezoe.birchill
Target Milestone: --- → Firefox 72
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.