Closed Bug 1803740 Opened 1 year ago Closed 11 months ago

Desktop site is automatically zoomed in

Categories

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

Firefox 107
All
Android
defect

Tracking

()

RESOLVED FIXED
116 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox108 --- wontfix
firefox109 --- wontfix
firefox110 --- wontfix
firefox111 --- wontfix
firefox114 --- wontfix
firefox115 --- wontfix
firefox116 --- fixed

People

(Reporter: pandazeng, Assigned: hiro)

References

Details

Attachments

(10 files)

Attached image diff.jpg

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36

Steps to reproduce:

1、load www.baidu.com
2、Toggle to desktop site

Actual results:

1、The page is automatically zoomed in and cannot be fully displayed on the screen
2、Not only the above site, many other sites have the same issue, but chrome does not have this issue
3、Other Geckovew based browsers like Focus, Wolvic etc. also have this issue

The attachment shows the different performance on Fenix and Chrome

Expected results:

1、The page is not zoomed in and can be fully displayed on the screen

The severity field is not set for this bug.
:cpeterson, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(cpeterson)

Thanks for reporting this bug. I'll test and share with the Fenix engineers.

Do you know offhand if this is a new bug?

Severity: -- → S3
Component: Browser Engine → General
Flags: needinfo?(cpeterson)
Product: Fenix → GeckoView
Flags: qe-verify+

(In reply to Chris Peterson [:cpeterson] from comment #2)

Thanks for reporting this bug. I'll test and share with the Fenix engineers.

Do you know offhand if this is a new bug?

Sorry, I don't known if it is a new bug。I found this bug when I used GeckoView in my own project, and checked it on Fenix and other GeckView based browsers

Attached image Zoom.jpg

Hi! I was able to reproduce the issue on Firefox 107, Firefox 108, Firefox 109.0b2 and on latest Nightly 110.0a1 from 20/12 with Motorola Moto G9 plus (Android 11).
Please check the new screenshot attached.

Flags: qe-verify+

Thanks for confirming the bug.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Does this affect sites other than Baidu?

Sounds like a Gecko issue.

Severity: S3 → --
Component: General → Panning and Zooming
Product: GeckoView → Core

(In reply to Chris Peterson [:cpeterson] from comment #7)

Does this affect sites other than Baidu?

Sounds like a Gecko issue.

Not only Baidu, many other sites also have this issue, such as:
bilibili.com
iqiyi.com
youku.com
www.qq.com
……

It does look like a Gecko issue.

Whiteboard: [apz-android-needstriage]

Adina, are you able to reproduce this issue on GeckoView example? I can't see any issue on the latest GeckoView example.

Flags: needinfo?(adina.petridean)
Attached image iqiyi.png
Flags: needinfo?(adina.petridean)

I can't reproduce this issue on the GeckoView example. I can't test with www.baidu.com but I tested it with www.iqiyi.com. Please check the new screenshot attached.

Great, thanks for testing. So, my best guess is that the sites provide different HTMLs depending on UA or it's a Fenix specif issue. Back to Fenix component for now.

(Note that I was initially suspecting that the reason why the sites works on Chrome is due to https://bugs.chromium.org/p/chromium/issues/detail?id=986674)

Component: Panning and Zooming → General
Product: Core → Fenix
Whiteboard: [apz-android-needstriage]

(In reply to Zeng Run from comment #0)

3、Other Geckovew based browsers like Focus, Wolvic etc. also have this issue

Hmm, maybe I am missing something...

(In reply to Adina Petridean from comment #12)

I can't reproduce this issue on the GeckoView example. I can't test with www.baidu.com but I tested it with www.iqiyi.com. Please check the new screenshot attached.

The attached picture shows that you are testing the mobile site, you should switch to the desktop site to reproduce it. I can reproduce with GeckoView when I change the UserAgentMode to USER_AGENT_MODE_DESKTOP

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

Great, thanks for testing. So, my best guess is that the sites provide different HTMLs depending on UA or it's a Fenix specif issue. Back to Fenix component for now.

(Note that I was initially suspecting that the reason why the sites works on Chrome is due to https://bugs.chromium.org/p/chromium/issues/detail?id=986674)

I think it is a GeckoView issue, I can reproduce it with GeckoView

(In reply to Adina Petridean from comment #12)

I can't reproduce this issue on the GeckoView example. I can't test with www.baidu.com but I tested it with www.iqiyi.com. Please check the new screenshot attached.

You can try
https://www.iqiyi.com/v_16hylv6glac.html?r_area=rec_you_like&r_source=230&bkt=MBA_PW_T3_57&e=611f24bc0a9d651ceca478d3d10f53e8&stype=2&vfrm=pcw_home&vfrmblk=712211_cainizaizhui&vfrmrst=712211_cainizaizhui_image1 with

Zen Run I attached another screenshot with the results for the link you suggested.
Regarding Comment 11, please note that the desktop switcher was enabled for all tests performed.

Attached image NewAttachment.png

(In reply to Adina Petridean from comment #18)

Zen Run I attached another screenshot with the results for the link you suggested.
Regarding Comment 11, please note that the desktop switcher was enabled for all tests performed.

It looks like you were redirected to a mobile site starting with m.iqiyi. this is what I see in Fenix:

(In reply to Adina Petridean from comment #18)

Zen Run I attached another screenshot with the results for the link you suggested.
Regarding Comment 11, please note that the desktop switcher was enabled for all tests performed.

Maybe you can try to switch the desktop version on another site first, and then enter this URL in the address bar, it should not be redirected. Or is there any way I can show you my screen recording video?

(In reply to Zeng Run from comment #22)

(In reply to Adina Petridean from comment #18)

Zen Run I attached another screenshot with the results for the link you suggested.
Regarding Comment 11, please note that the desktop switcher was enabled for all tests performed.

Maybe you can try to switch the desktop version on another site first, and then enter this URL in the address bar, it should not be redirected. Or is there any way I can show you my screen recording video?

Zeng Run thank you for the attached video. Following your steps I was able to take a screenshot on Nightly 110.0a1 with the https://www.iqiyi.com/v_16hylv6glac.html?r_area=rec_you_like&r_source=230&bkt=MBA_PW_T3_57&e=611f24bc0a9d651ceca478d3d10f53e8&stype=2&vfrm=pcw_home&vfrmblk=712211_cainizaizhui&vfrmrst=712211_cainizaizhui_image1 website, but I can't do it on Geckoview without being redirected to the m.iqiyi....... Can you please share a video of the GeckoView example as well?

(In reply to Adina Petridean from comment #24)

(In reply to Zeng Run from comment #22)

(In reply to Adina Petridean from comment #18)

Zen Run I attached another screenshot with the results for the link you suggested.
Regarding Comment 11, please note that the desktop switcher was enabled for all tests performed.

Maybe you can try to switch the desktop version on another site first, and then enter this URL in the address bar, it should not be redirected. Or is there any way I can show you my screen recording video?

Zeng Run thank you for the attached video. Following your steps I was able to take a screenshot on Nightly 110.0a1 with the https://www.iqiyi.com/v_16hylv6glac.html?r_area=rec_you_like&r_source=230&bkt=MBA_PW_T3_57&e=611f24bc0a9d651ceca478d3d10f53e8&stype=2&vfrm=pcw_home&vfrmblk=712211_cainizaizhui&vfrmrst=712211_cainizaizhui_image1 website, but I can't do it on Geckoview without being redirected to the m.iqiyi....... Can you please share a video of the GeckoView example as well?

I uploaded a new attachment. In my GeckoView Demo, I set the UserAgentMode of GeckoSessionSettings to GeckoSessionSettings.USER_AGENT_MODE_DESKTOP, and then opened the following two websites:

  1. https://www.baidu.com
  2. https://www.iqiyi.com/v_2cxzcwcec64.html?r_area=pcw_rec_like&bkt=tpfsfallrerank_07%3Btp_fsfall_rule_13%3Btpfsfallrank_03%3Btp_fsfall_prerank_08&e=44035e07887a8cf9b4585364bc0a1b2f&stype=2&vfrm=pcw_home&vfrmblk=712211_cainizaizhui&vfrmrst=712211_cainizaizhui_image1

Though I am not sure about what USER_AGENT_MODE_DESKTOP means, VIEWPORT_MODE_DESKTOP looks the proper one.

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

Though I am not sure about what USER_AGENT_MODE_DESKTOP means, VIEWPORT_MODE_DESKTOP looks the proper one.

Maybe you can check the source code of GeckoSessionSettings.Builder to know what USER_AGENT_MODE_DESKTOP means. This is my demo:

GeckoSessionSettings geckoSettings = new GeckoSessionSettings.Builder()
.usePrivateMode(false)
.userAgentMode(GeckoSessionSettings.USER_AGENT_MODE_MOBILE)
.viewportMode(GeckoSessionSettings.VIEWPORT_MODE_DESKTOP)
.build();

I set both USER_AGENT_MODE_DESKTOP and VIEWPORT_MODE_DESKTOP. If only VIEWPORT_MODE_DESKTOP is set, the site will be redirected to the mobile version (m.xxx.xxx), because the default userAgentMode of GeckoView is USER_AGENT_MODE_MOBILE. So if you want to access the desktop version of the site, it seems that you need to set userAgentMode at the same time. I believe Firefox does this too, so it can reproduce this issue

Tried to test this using iqiyi.com and saw that indeed on Fenix and Focus the issue is reproduceable with desktop mode giving the non-mobile page which indeed starts as zoomed in.
On GVE I always get the mobile page - m.iqiyi.com and I understand from @Zeng that if we'd manage to load the desktop site we'd get the problem to reproduce here also.
(Not sure why GVE always loads the mobile version, maybe this could be looked at separately as an issue which could prevent debugging other problems also)
Without tinkering more with GVE to load the desktop page I still don't think this is a Fenix/Focus issue as we are not really doing to directly change page zooming/layout.

The severity field is not set for this bug.
:cpeterson, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(cpeterson)

I do think it would be interesting to understand the behaviour of MobileViewportManager when this page is loaded in Fenix.

With MVM logging enabled, I do see this line printing ShrinkToDisplaySize using scrollableRect (1250 x 1944.45), which I think should cause us to zoom out (since the viewport width is 980, the "desktop mode" default), but we don't. Unfortunately, the logs don't say which of these conditions is failing.

Whiteboard: [apz-android-needstriage]
Assignee: nobody → botond
Status: NEW → ASSIGNED
Assignee: botond → nobody
Status: ASSIGNED → NEW

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

the logs don't say which of these conditions is failing.

The most suspicious condition there is !viewportInfo.IsDefaultZoomValid(). If there's a reasonable initial-scale value, the condition would be false.

There may be multiple meta viewport tags and some of them are modified (or removed)? It makes me suspect again the Chrome bug in comment 13.

Assignee: nobody → botond
Status: NEW → ASSIGNED
Pushed by bballo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ed2ca4f9d6f6
Add logging to explain why MobileViewportManager didn't perform shrink-to-fit. r=hiro
Keywords: leave-open

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

The most suspicious condition there is !viewportInfo.IsDefaultZoomValid(). If there's a reasonable initial-scale value, the condition would be false.

It looks like there are others ways we can have IsDefaultZoomValid() == true. In this ForceDesktopViewport() branch, we use this nsViewportInfo constructor which sets mDefaultZoomValid = true. (And it looks like VIEWPORT_MODE_DESKTOP causes us to take that branch.)

So here is an STR with a minimal testcase:

  1. Load https://theres-waldo.github.io/mozilla-testcases/grid-no-meta.html (it's a page with a content size 2000x4000 and no meta viewport tag)
  2. Switch to desktop mode

In Fenix, the page loads somewhat zoomed in (specifically, at a zoom level that fits the 980px desktop viewport width into the screen width).

In Chrome, the page loads zoomed as far out as the built-in minimum scale of 0.25x will allow (on my device, with a 1080px screen width and a 3.0 device scale (meaning the screen width is 360 CSS pixels at unit zoom), it fits 1440px of the page content into the screen width).

Based on the above findings, this is an APZ issue.

Component: General → Panning and Zooming
Flags: needinfo?(cpeterson)
Product: Fenix → Core
Severity: -- → S3
Priority: -- → P2

So the unexpected mDefaultZoomValid == true info comes from this ForceDesktopViewport() branch as Botond mentioned in 36.

The branch was introduced in bug 1202713, it's before we introduced the minimum-scale concept on mobile.

There's a big question. "What's the VIEWPORT_MODE_DESKTOP supposed to be?" As you guys already know, on desktop browsers the zoom level can't be less than 1.0. Applying minimum-scale stuff will result what the original bug reporter wants, but is it really what VIEWPORT_MODE_DESKTOP should be?

Given that there's a browser on a desktop environment and the browser's window width is 980px, layouting 2000x4000 content should fit to the browser width? Or the content should be scrolled out horizontally?

Fixing as what the reporter wants should be easy (I will post a patch), but I'd like to hear opinions from the product design perspective. I am not sure who is the right person, so I'd start with :cpeterson.

Chris, can you please redirect to the proper person about a question "what the 'Desktop site' option should be?"? I don't know there's an equivalent option on mobile Safari, if there is and if it's same as what Chrome does, we should do the same thing.

Flags: needinfo?(cpeterson)

Chris, can you please redirect to the proper person about a question "what the 'Desktop site' option should be?"? I don't know there's an equivalent option on mobile Safari, if there is and if it's same as what Chrome does, we should do the same thing.

Thanks for the heads up. I asked Android PM and UX to share their feedback here.

Hiro, given your experience with layout, do you have an opinion?

Flags: needinfo?(cpeterson) → needinfo?(hikezoe.birchill)

I would say that laying out on the device width with zoom=1.0. Several years ago most of device screen sizes are pretty small, but it's getting larger and larger. So now shrink-to-fit isn't so important on __desktop__mode I suppose. That said, my opinion probably is far different from users/web-developers perspectives.

Flags: needinfo?(hikezoe.birchill)

I should have posted at least one example that we can see a difference between normal desktop mode view and desktop view with applying minimum-scale stuff.

Attaching file is an example (modified https://bokand.github.io/demo/urlbarsize.html).

If you open the example on desktop browsers, you will see four vertical bars at the right of the content.

If you open the example on mobile browsers with desktop mode, you will see two orange bars in the middle of the content.

Dropping [apz-android-needstriage] since now we know why we don't apply minimum-scale stuff. A remaining issue here is that whether we should apply <1.0 initial scale value on desktop view mode.

Whiteboard: [apz-android-needstriage]

Chris, just checking back in on this for the team. Have you gotten feedback from UX or the PM on this? If we have their guidance, we are ready to move forward on this. Thanks.

Flags: needinfo?(cpeterson)

(In reply to Frank Griffith Jr from comment #45)

Chris, just checking back in on this for the team. Have you gotten feedback from UX or the PM on this? If we have their guidance, we are ready to move forward on this. Thanks.

Not yet, so I've asked for an Android engineer to review Hiro's test case and reply in this bug.

Flags: needinfo?(cpeterson)
See Also: → 1836389

We decided we make our behavior match to Chrome's in this bug. I filed bug 1836389 for making a decision what "desktop mode" should be.

Attachment #9330942 - Attachment description: WIP: Bug 1803740 - Apply the minimum-scale for desktop mode. → Bug 1803740 - Apply the minimum-scale for desktop mode. r?botond
Assignee: botond → hikezoe.birchill
Keywords: leave-open
Pushed by hikezoe.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ed1803ee0338
Apply the minimum-scale for desktop mode. r=botond
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → 116 Branch
Flags: needinfo?(hikezoe.birchill)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: