1875041 - PDF pages should not be opened in desktop mode regardless of the parent tab and desktop mode by default

Status: RESOLVED FIXED

(GeckoView :: PDF Viewer, defect)

Description

[Mira Lobontiu (Android QA)]

Attachment: az_recorder_20240117_121151.mp4

Steps to reproduce

1. Open a PDF page in Firefox for Android (i.e. https://research.nhm.org/pdfs/10840/10840.pdf).
2. From the three-dot menu, enable the "Desktop site" toggle.

Expected behavior

The PDF page should not modify.

Actual behavior

The "Download" and "Open in app" options shrink. The PDF page is slightly modified - please see the attached short video.

Device information

• Firefox version: all (121.1.0, 122.0, Beta 122.0b9, and Nightly 123.0a1 from 1/17)
• Android devices: Samsung Galaxy A14 (Android 13), Google Pixel 8 (Android 14)

Any additional information?

• Also reproducible on Focus Nightly 123.0a1 from 1/16.

Comment 1

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

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

Comment 2

[Nicholas Poon (redirect NI to [e-mail]) [:Nick]]

Since toggling Desktop mode will be disabled on PDF pages in Bug 1920090, I will close this bug as a dupe

Comment 3

[Nicholas Poon (redirect NI to [e-mail]) [:Nick]]

Reopening because opening a PDF child tab from a parent tab with desktop mode enabled will lead to the PDF tab being opened with desktop mode enabled. Now that desktop mode by default is also in fenix, PDFs opened on tablets will also open in desktop mode.

There may be a better way to fix this but Rahul suggested that 1 solution can be adding a "notPdf" check here

Comment 4

[Iorga Gabriel]

So if the tab is a PDF, the "Desktop site" toggle should be hidden, and the tab should open with desktop mode disabled?

Comment 5

[Olivia Hall [:olivia]]

This bug could also likely be fixed on the PDF.js platform side. The PDF toolbar is drawn from there. It is probably using the same size chart to scale the toolbar that Desktop uses for when Desktop mode is enabled.

Calixte, what is your impression of this bug? We could probably solve it on the front-end Android layer by adding checks for Desktop mode before loading, but it seems like it might be more solidly fixed when the toolbar is drawn by PDF.js. I'm guessing an @media needs to be adjusted somewhere in viewer-geckoview.css possibly? Please let us know what you think.

Comment 6

[Olivia Hall [:olivia]]

Also, I think one problem with trying to solve this on the front-end Fenix layer is also that we will not know the value of isPDF until after the PDF is loaded. So, any front-end solution is going to require a reload.

Another fix might be on the GeckoView layer turning-off Desktop mode for PDFs, but it would probably require a reload as well, since right now we will know after the fact that it is a PDF.

Comment 7

[Nicholas Poon (redirect NI to [e-mail]) [:Nick]]

Hey Olivia,
Is the toolbar the only difference when we toggle the desktop mode on PDFs? It seems like Bug 1934393 (in see also) suggests that the touch area may change also

Comment 8

[Olivia Hall [:olivia]]

Hi Nick,

Thanks for sharing that connection, that bug is very interesting!

To summarize over here what is going on in bug 1934393, scrolling is having issues with zones not responding on PDFs on Android opened with Desktop Mode on. From the discussion, it sounds like desktop mode is the breaking factor.

A few comments from over there especially catch my attention:

Scrolling mostly works on the left side of the screen (not 100% reliably) and does completely not work on the right side (dead zone).

Just realized the same issue happens with the pdf.js demo https://mozilla.github.io/pdf.js/web/viewer.html but only on Firefox Fenix, so I'm not sure if this is a pdf.js issue or a Fenix issue.

Yes this seems to be the issue, without desktop mode it works fine, and with desktop mode the bug appears.

Though opening PDFs without desktop mode makes them very small at first, so one needs to zoom in everytime when opening a PDF without desktop mode, would be great if this could be fixed in the desktop mode!

Comment 9

[Iorga Gabriel]

Attachment: Bug 1875041 - Hide Desktop site menu item when content is PDF.

Comment 10

[Calixte Denizet (:calixte)]

(In reply to Olivia Hall [:olivia] from comment #5)

This bug could also likely be fixed on the PDF.js platform side. The PDF toolbar is drawn from there. It is probably using the same size chart to scale the toolbar that Desktop uses for when Desktop mode is enabled.

Calixte, what is your impression of this bug? We could probably solve it on the front-end Android layer by adding checks for Desktop mode before loading, but it seems like it might be more solidly fixed when the toolbar is drawn by PDF.js. I'm guessing an @media needs to be adjusted somewhere in viewer-geckoview.css possibly? Please let us know what you think.

:olivia, what's exactly the "desktop mode" ?
The toolbar height is defined here:
https://searchfox.org/mozilla-central/source/toolkit/components/pdfjs/content/web/viewer-geckoview.css#1523
and is a value in pixels. So is the resolution (i.e. devicePixelRatio) changed ?
In such a case, we'd have to change the height to something like 48px * devicePixelRatio.

Comment 11

[Olivia Hall [:olivia]]

Thanks for taking a look, Calixte!

what's exactly the "desktop mode"

• Both the user agent and viewport change. (Set from here in AC. )
• The user agent is set to Desktop
• The viewport is set to Desktop - webidl - I haven't spotted the exact definition yet of what this defaults to
• Reloads the URL
• Once the mode is enabled, the mode will stay on/off like a toggle
• Hiding the browser menu option on PDFs doesn't fully stop the problem because desktop mode can be on before navigation to the PDF. So, we can hide the option, but if it is already on, then the problem will still be there. We also don't know isPDF until after load, IIRC, so setting it out of desktop mode would require a reload and also tracking the state to set it back once not on a PDF. We could probably do this as a workaround, but it seems like it isn't solving the root issues.
• Some of the items reported in bug 1934393 sound interesting and likely related as well in terms of unique issues the mode is causing on PDFs.

Comment 12

[Olivia Hall [:olivia]]

Copy and pasting a comment I left on the patch here for visibility:

My impression of this bug is that it needs both platform and likely product or UX support.

Reason product or UX support would be good here:
On the one hand, some of this behavior is "works as expected". Desktop mode is there for users wanting to change the viewport and user agent. In that sense, the PDF is rendering as expected for the given viewport, which is why the toolbar is tiny. However, it isn't a good experience if the user doesn't know that they are in Desktop mode. It would be nice if we had feedback from a UX/product partner on potential solutions. For example, maybe the PDF toolbar should grow to the larger size even in Desktop mode. Maybe we add a toggle to the PDF.js toolbar of "Desktop mode is enabled". Maybe we show a warning of "you are in Desktop mode, do you mean to be?" There are many potential solutions and right ways to go about fixing this experience.

Reason why a platform or PDF.js solution would be good here
When I looked through the code, my impression is Fenix does not know isPDF's value until after load. So, to solve the issue of already having Desktop mode enabled on the AC/Fenix side means we would have to:

1. Check that it is a PDF post-load
2. Toggle off Desktop mode
3. Track what the prior value of Desktop mode was
4. Reload the PDF page with Desktop mode off
5. Reengage the prior Desktop mode value on navigation

A solution like this would be fragile and the user would almost certainly see the reload.

However, if this was solved on the PDF.js side through resizing the toolbar / redefining the pdf.js behavior in Desktop mode, the solution would be much more straightforward and robust. Additionally, the tangential information in bug 1934393 makes it sound like a refresh on the PDF.js side for Desktop mode could improve a lot of the issues.

One issue I see with the current solution of hiding the option on the toolbar on the PDF right now is that if the user has already engaged Desktop mode, then they can't engage back out of it on the PDF.

Comment 13

[Iorga Gabriel]

Needs UX

Comment 14

[Iorga Gabriel]

Attachment: Bug 1875041 - Hide Desktop site menu item when content is PDF.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/125e32e29ad1
Hide Desktop site menu item when content is PDF. r=android-reviewers,calu,ohall

Comment 16

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/125e32e29ad1