1803740 - Desktop site is automatically zoomed in

Status: RESOLVED FIXED

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

Description

[Zeng Run]

Attachment: 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

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 2

[Chris Peterson [: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?

Comment 3

[Zeng Run]

(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

Comment 4

[Adina Petridean QA [:apetridean]]

Attachment: Zoom.jpg

Comment 5

[Adina Petridean QA [:apetridean]]

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.

Comment 6

[Chris Peterson [:cpeterson]]

Thanks for confirming the bug.

Comment 7

[Chris Peterson [:cpeterson]]

Does this affect sites other than Baidu?

Sounds like a Gecko issue.

Comment 8

[Zeng Run]

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

Comment 9

[Zeng Run]

Another zoomed-in page：
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

Comment 10

[Hiroyuki Ikezoe (:hiro)]

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

Comment 11

[Adina Petridean QA [:apetridean]]

Attachment: iqiyi.png

Comment 12

[Adina Petridean QA [:apetridean]]

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.

Comment 13

[Hiroyuki Ikezoe (:hiro)]

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)

Comment 14

[Hiroyuki Ikezoe (:hiro)]

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

Comment 15

[Zeng Run]

(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

Comment 16

[Zeng Run]

(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

Comment 17

[Zeng Run]

(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

Comment 18

[Adina Petridean QA [:apetridean]]

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.

Comment 19

[Adina Petridean QA [:apetridean]]

Attachment: NewAttachment.png

Comment 20

[Zeng Run]

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

Comment 21

[Zeng Run]

Attachment: 1fad3af1e645a0bd18656ff378b1a762.jpg

Comment 22

[Zeng Run]

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

Comment 23

[Zeng Run]

Attachment: c053cc9cebbe4b4ff0b293e3c8e7961b.mov

Comment 24

[Adina Petridean QA [:apetridean]]

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

Comment 25

[Zeng Run]

Attachment: geckoview_screenshot.mov

Comment 26

[Zeng Run]

(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

Comment 27

[Hiroyuki Ikezoe (:hiro)]

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

Comment 28

[Zeng Run]

(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

Comment 29

[Petru-Mugurel Lingurar [:petru]]

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.

Comment 30

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 31

[Botond Ballo [:botond]]

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.

Comment 32

[Botond Ballo [:botond]]

Attachment: Bug 1803740 - Add logging to explain why MobileViewportManager didn't perform shrink-to-fit. r=hiro

Comment 33

[Hiroyuki Ikezoe (:hiro)]

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

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ed2ca4f9d6f6
Add logging to explain why MobileViewportManager didn't perform shrink-to-fit. r=hiro

Comment 35

[Botond Ballo [:botond]]

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

Comment 36

[Botond Ballo [:botond]]

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

Comment 37

[Botond Ballo [:botond]]

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

Comment 38

[Iulian Moraru]

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

Comment 39

[Hiroyuki Ikezoe (:hiro)]

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.

Comment 40

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1803740 - Apply the minimum-scale for desktop mode. r?botond

Comment 41

[Chris Peterson [: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?

Comment 42

[Hiroyuki Ikezoe (:hiro)]

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.

Comment 43

[Hiroyuki Ikezoe (:hiro)]

Attachment: an example which causes different layout results with applying minimum-scale stuff

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.

Comment 44

[Hiroyuki Ikezoe (:hiro)]

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.

Comment 45

[Frank Griffith Jr]

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.

Comment 46

[Chris Peterson [: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.

Comment 47

[Hiroyuki Ikezoe (:hiro)]

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.

Comment 48

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ed1803ee0338
Apply the minimum-scale for desktop mode. r=botond

Comment 49

[Norisz Fay [:noriszfay]]

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

Comment 50

[Ryan VanderMeulen [:RyanVM]]

nvm, misread