Closed Bug 1762255 Opened 3 years ago Closed 2 years ago

Small pages not zooming out 100% in Android

Categories

(Core :: Panning and Zooming, defect, P2)

Product:
Core
Component:
Panning and Zooming
Version:
Firefox 98
Platform:
Unspecified
Android
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
112 Branch
Tracking Flags:
Tracking Status
firefox-esr102 --- wontfix
firefox110 --- wontfix
firefox111 --- wontfix
firefox112 --- fixed

People

(Reporter: cacho96, Assigned: hiro)

References

Details

Attachments

(2 files)

The test case in comment 0
195 bytes, text/html
Details
Bug 1762255 - Convert MobileViewport intrinric size to app units and use it in the comparison. r?tnikkel,botond
48 bytes, text/x-phabricator-request
Details | Review

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

I have this very simple W3C valid HTML that Firefox for Android refuses to render in 100% view:

<!DOCTYPE html>
<html lang="pt">
<head>
<title>Devastacao por lei</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<h3>Nothing here</h3>
</body>
</html>

No matter how much I pinch out, Firefox still renders the horizontal scrollbar and allows me to move the text right and left (i.e., scroll the page horizontally). I can zoom in, but I cannot zoom out to the point that I cannot scroll left/right without moving the text/page.

I tried fiddling with the Accessibility settings without luck. Tried with about:config, but it shows nothing.

Chrome renders the page perfectly.

It turns out that only happens when the height of the page is smaller than the device height, that is, when the full page fits in height, AND when "Scroll to hide toolbar" is ON in Settings - Customize.

To check this, just add lines after the <h3>Nothing here</h3> of the form test<br> one by one. You will see the same problem. Keep adding lines until, suddenly, the page does not fit anymore in height. Then the page finally fits in width if pinched out, and everything works just fine.

WORKAROUND:

Just add this line to your HTML:

<div style="height: 101vh;visibility: hidden;"></div>

or, better, adjust the height to your page.

Notice that this will make the scrollbar to appear, and that the page will scroll even if there is "nothing" in the bottom. Setting overflow:hidden; for body or html prevents the workaround from working.

THIS BUG IS REPORTED IN STACKOVERFLOW:
https://stackoverflow.com/questions/71561637/bug-in-firefox-for-android-small-pages-not-zooming-out-100/71680893#71680893

Actual results:

After zooming in, the page "jumps" and cannot be fitted in width.

Expected results:

Fit in width.

The Bugbug bot thinks this bug should belong to the 'Core::Panning and Zooming' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Panning and Zooming
Product: Firefox → Core

BTW, the user agent in the report is incorrect (I was in my Linux box). The correct one is:

Mozilla/5.0 (Android 11; Mobile; rv:98.0) Gecko/98.0 Firefox/98.0

Probably there's something mistake in zoom ratio restriction calculation.

BTW, is there any strong reason why <meta name="viewport" content="width=device-width"> isn't used?

Hmm I can't reproduce on GeckoView example.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)

BTW, is there any strong reason why <meta name="viewport" content="width=device-width"> isn't used?

Of course in that particular page it would be ok to add the meta. But in complex pages that meta usually gives me lots of other troubles. I used to use it, but I eventually gave up. It's probably my fault, but...

(In reply to Hiroyuki Ikezoe (:hiro) from comment #4)

Hmm I can't reproduce on GeckoView example.

For what it's worth, I'm able to reproduce the described behavior on https://example.com (which has <meta name="viewport" content="width=device-width, initial-scale=1" />) with GVE 2022-04-04 (48ee5b88) on a Pixel 5a running Android 12 (SP2A.220305.012). Let me know if there's anything I can do to help.

Interestingly, for me, the test case from comment 0 does not render a horizontal scrollbar even when zoomed in.

(example.com does render a horizontal scrollbar when zoomed in, and it correctly goes away for me when zooming back out. My guess is the issue is caused by some sort of rounding error, and it's dependent on the screen dimensions.)

Comment on attachment 9270336 [details] The test case in comment 0 ><!DOCTYPE html> ><html lang="pt"> ><head> ><title>Devastacao por lei</title> ><meta http-equiv="Content-Type" content="text/html; charset=utf-8"> ></head> ><body> ><h3>Nothing here</h3> ></body> ></html>
Attachment #9270336 - Attachment description: The test case in commen 0 → The test case in comment 0

(In reply to Botond Ballo [:botond] from comment #8)

Interestingly, for me, the test case from comment 0 does not render a horizontal scrollbar even when zoomed in.

I guess I'm running into a different bug, which may be obscuring my ability to reproduce this one. Filed bug 1763480 for this.

See Also: → 1763480

Mark this as severity 3 (I assume the superfluous horizontal scrollbar is more just a distraction / eyesore and doesn't interfere with the functionality of a web app in any significant way).

Severity: -- → S3
Priority: -- → P3

I added the line

          <meta name="viewport" content="width=device-width, initial-scale=1" />

to the headers of all my webpages, and that solved the issue. Almost.... I just noticed that with modal DIVs the same problem happens, even when the page has the above line in the headers. Unfortunately, I cannot say why, but you can check it here:

       https://luis.impa.br/photo/2201_aves_Caracarai-RR/index.html

If you zoom in/out this page you will find no problem, since it already has the meta line included. But if you first click on a thumbnail, a fullscreen modal DIV will open the full image, and if you zoom in you will see that you cannot zoom out completely. Notice that the DIV is not included in the source of the page, but added in javascript. Again, this happens only when "Scroll to hide toolbar" is ON in settings.

I don't know if this is relevant or not to this issue, but I found another inconsistency: Firefox reports slightly bigger screen dimensions relative to Chrome and Android Webview. See here: https://stackoverflow.com/questions/71745103/screen-width-battle-webview-vs-firefox-vs-chrome

(In reply to Luis from comment #13)

I don't know if this is relevant or not to this issue, but I found another inconsistency: Firefox reports slightly bigger screen dimensions relative to Chrome and Android Webview. See here: https://stackoverflow.com/questions/71745103/screen-width-battle-webview-vs-firefox-vs-chrome

I'm not sure if it's relevant either, but I would suggest filing a separate issue about it in the GeckoView component so that we don't lose track of it.

Bug 1526940 is an earlier report with similar symptoms which may be related.

See Also: → 1526940

(In reply to Botond Ballo [:botond] from comment #14)

(In reply to Luis from comment #13)

I don't know if this is relevant or not to this issue, but I found another inconsistency: Firefox reports slightly bigger screen dimensions relative to Chrome and Android Webview. See here: https://stackoverflow.com/questions/71745103/screen-width-battle-webview-vs-firefox-vs-chrome

I'm not sure if it's relevant either, but I would suggest filing a separate issue about it in the GeckoView component so that we don't lose track of it.

Done here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1763935

(In reply to Luis from comment #12)

I added the line

          <meta name="viewport" content="width=device-width, initial-scale=1" />

to the headers of all my webpages, and that solved the issue. Almost.... I just noticed that with modal DIVs the same problem happens, even when the page has the above line in the headers. Unfortunately, I cannot say why, but you can check it here:

       https://luis.impa.br/photo/2201_aves_Caracarai-RR/index.html

If you zoom in/out this page you will find no problem, since it already has the meta line included. But if you first click on a thumbnail, a fullscreen modal DIV will open the full image, and if you zoom in you will see that you cannot zoom out completely. Notice that the DIV is not included in the source of the page, but added in javascript. Again, this happens only when "Scroll to hide toolbar" is ON in settings.

Thanks, I can reproduce the issue on the modal div page.

It does look dynamic toolbar related. In particular, it looks like after zooming in, the toolbar hides, and the minimum scale "jumps" to a value where the height of the page fills the vertical space made available by the toolbar hiding, while preserving the width:height ratio (which now makes the width scrollable). This minimum scale then persists even if the toolbar reappears.

Bumping this to a P2 as now we have something actionable to investigate.

Priority: P3 → P2

Looks like the site does change overflow style on the body element from auto to hidden when the image gets fullscreened. We handled the case in bug 1740289 to show the dynamic toolbar again. Probably we have to do minimum scale stuff too? Though I supposed that the overflow style change case should be handled via reflow calls.

See Also: → 1740289

Just found another issue that seems closely related.
Look at this page:

     https://luis.impa.br/photo/galsearch.html

If you have "Scroll to hide folder" activated in settings
and click on the input form, the page zooms in without
any reason.

Again, observe that this is a page that fills the full screen.
These seem to be the two precise conditions for this bug
to show up: "Scroll to hide folder" + page fitting screen.

(In reply to Luis from comment #19)

Just found another issue that seems closely related.
Look at this page:

     https://luis.impa.br/photo/galsearch.html

If you have "Scroll to hide folder" activated in settings
and click on the input form, the page zooms in without
any reason.

While this doesn't happen on my phone (likely dependent on screen size), zooming in when an input field gets focus in general is a long-standing and expected behaviour (called "zoom to focused input") that's been in place since at least 2012 (bug 725018).

(In reply to Botond Ballo [:botond] from comment #20)

(In reply to Luis from comment #19)

Just found another issue that seems closely related.
Look at this page:

     https://luis.impa.br/photo/galsearch.html

If you have "Scroll to hide folder" activated in settings
and click on the input form, the page zooms in without
any reason.

While this doesn't happen on my phone (likely dependent on screen size), zooming in when an input field gets focus in general is a long-standing and expected behaviour (called "zoom to focused input") that's been in place since at least 2012 (bug 725018).

This only happens with "Scroll to hide folder" on, and the zoom stays on even after the input loosing its focus.

(In reply to Luis from comment #21)

This only happens with "Scroll to hide folder" on, and the zoom stays on even after the input loosing its focus.

Thanks, it sounds like it may be running into the same underlying bug as comment 17 then. We should re-test this page after that issue is fixed.

It looks like there's something device specific (device's screen resolution?) thing. I don't see the issue on GeckoView example on Android emulator, don't see the issue on Fenix on AQUOS Sense 3 either. Whereas I can see the issue on Fenix both on my Pixel 3 and Pixel 6a. And interestingly on Pixels the dynamic toolbar moves as if the content is overflowed.

Okay, I've checked it happens on GeckoView example as well on my Pixel 3. And this looks also caused by pixel alignment or rounding error in nsLayoutUtils::UpdateCompositionBoundsForRCDRSF;

        if (intrinsicCompositionSize.height <                                   
              CSSPixel::FromAppUnits(                                             
                  CalculateScrollableRectForFrame(rootScrollableFrame, nullptr)   
                      .Height())) {                                               
            shouldSubtractDynamicToolbar = SubtractDynamicToolbar::No;            
          }

On the device the intrinsicCompositionSize.height is 1630.61, the CalculateScrollableRectForFrame height is 1630.62.

Okay, the difference comes from this CSSSize::ToAppUnits for mMinimumScaleSize.

Our MobileViewportManager's intrinsic scale size is 1.10204, minScale value in ScrollFrameHelper::UpdateMinimumScaleSize is also 1.10204. Both display sizes in MobileViewportManager and ScrollFrameHelper are same, (1080 x 1797). Then 1797 / 1.10204 = 1630.61231897 which is approximately equals to 1630.61 (== the intrinsicCompositionSize.height). And converting 1630.61 to app units is rounded to 97837. And converting 97837 back to CSS units results 1630.62 unfortunately.

So there are two options I can think of,

a) Convert this intrintisCompositionSize to app units, then compare it with CalculateScrollableRectForFrame() value in app units
b) Store the mMinimumScaleSize (and relevant metrics) in CSS units and provide another variant of CalculateScrollableRectForFrame but in CSS units

I believe b) is ideal, but it will involve a lots of stuff. So for example, how the mMinimumScaleSize is exposed via CalculateScrollableRectForFrame is;

  1. the mMinimumScaleSize is set to this layoutSize variable
  2. it's used for this scrollPortSize
  3. and the scrollPortSize is stored as mScrollPort
  4. and it's used in the CalcualteScrollableRectForFrame function

So I'd rather take a) approach here.

Assignee: nobody → hikezoe.birchill
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Pushed by hikezoe.birchill@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ddd1ce6dd097 Convert MobileViewport intrinric size to app units and use it in the comparison. r=botond,geckoview-reviewers,m_kato

https://hg.mozilla.org/mozilla-central/rev/ddd1ce6dd097

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
status-firefox112: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 112 Branch
status-firefox110: --- → wontfix
status-firefox111: --- → wontfix
status-firefox-esr102: --- → wontfix
OS: Unspecified → Android
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: