Closed Bug 1823164 Opened 1 year ago Closed 1 year ago

Downloading PDFs is unintuitive on android

Categories

(Fenix :: General, defect, P1)

Firefox 112
All
Android

Tracking

(relnote-firefox 113+, firefox111- wontfix, firefox112 wontfix, firefox113 fixed, firefox114 fixed)

RESOLVED FIXED
114 Branch
Tracking Status
relnote-firefox --- 113+
firefox111 - wontfix
firefox112 --- wontfix
firefox113 --- fixed
firefox114 --- fixed

People

(Reporter: evilpie, Assigned: calixte)

References

Details

(Whiteboard: [fxdroid] [foundation] [Needs-UX])

Attachments

(3 files)

At least two users on reddit were unable to figure out how to download a PDF displayed by pdf.js. "Save as PDF" doesn't sound great to me when the opened document is already a PDF, instead of just "Download PDF".

The bottom of the share menu is maybe also not the immediately most obvious place to look.

Google Drive's PDF viewer has a "Download" entry in the meatball menu. I think this could be placed below the "Open in app" menu item, I think that makes sense contextually.

Yeah, I knew the share trick, but it's fairly obscure :)

Hi! I'm one of the aforementioned Reddit users. I think what was tripping me up was that, first, the PDF viewer lacked the features I typically expect in a browser's viewer, like the "download PDF" button or page layout selection, causing me to think this was a webpage linked through a broken download link (I didn't realise the browser had a built-in PDF viewer now); second, the option was contained in the meatballs menu, which isn't usually something that you use for interacting with a webpage and thus wasn't somewhere that it occurred to me to check; and third, when downloading something, I'm not expecting that feature to be found in the share menu (which I wasn't aware existed until now) because I'm not trying to share it with anyone.

I hope this helps with understanding my issue!

I agree that it's very unintuitive, as I was also very confused, especially because I pressed a site's download button, but instead of downloading, Firefox decided to open it instead. When I specifically press a download button, I'd like my browser to download it instead of opening it without downloading. Aside from moving the download button in the browser viewer to a more intuitive location, why not show a prompt with the question if the user wants to view or download the PDF in the first place?

Oh boy, came here to post this. I was expecting it to be at the top of the meatball menu, or at least where the open in app menu item is. Having to click one deeper into the share menu of all places didn't even occur to me. At least now I know it's there and can download PDFs again. A prompt to view or download might be nice, but idk what the average clicks would look like. Just sticking it at the top of the meatball menu would be good enough for me.

Apparently the save as pdf under share renames the file too, are we even saving the original file or is it reencoding it from the pdf.js rendering? If so, that's pretty damn bad. I need to be able to download the actual PDFs, not what gets filtered through another library.

I think it would better if Fenix add a "Save as PDF" button in context menu, so that user maybe easier to discover it. See also https://bugzilla.mozilla.org/show_bug.cgi?id=1808007, if it's a PDF file, download it directly, if itsn't, covnert to PDF first.

This issue produces a lot of support requests.

Blocks: 1803753

[Tracking Requested - why for this release]: A lot of confusion about this. Users think they can't download PDFs anymore.

Too late to address for 111.x or 112.0 (RC builds are happening on Monday), but keeping on the 112 radar in case there's a suitable patch available for a dot release ride-along.

Flags: needinfo?(cdenizet)

The way to download a pdf is to click on 3-dots button, then share and finally save as PDF.
I suppose that the users would like to have a button in the 3-dots menu or something like that.
I can likely write a patch to add a menu entry somewhere, but I need to know what "somewhere" is, to have an icon and the wording.

Anyway, I think this is more a product question than a technical one.

Flags: needinfo?(epiper)
Flags: needinfo?(cpeterson)
Flags: needinfo?(cdenizet)

(In reply to Calixte Denizet (:calixte) from comment #11)

The way to download a pdf is to click on 3-dots button, then share and finally save as PDF.
I suppose that the users would like to have a button in the 3-dots menu or something like that.

One thing to note about this method of saving PDFs is that this seems to rename PDFs differently than if downloaded directly (eg via another browser or wget). That is something else that should also be changed if this is added as a menu item. From my perspective, it introduces questions about whether Firefox is modifying the PDF in some way and transcoding the result.

Ideally, I want Firefox to save the PDF as it exists if I were to download it without viewing it first.

(In reply to Calixte Denizet (:calixte) from comment #11)

The way to download a pdf is to click on 3-dots button, then share and finally save as PDF.
I suppose that the users would like to have a button in the 3-dots menu or something like that.
I can likely write a patch to add a menu entry somewhere, but I need to know what "somewhere" is, to have an icon and the wording.

Anyway, I think this is more a product question than a technical one.

In my opinion, add a "more" button, it take the place of "Sync and save data", and it contains:
Save as PDF and more. Below is fennec 68's 3-dots menu:
https://cdn-us.imgs.moe/2022/12/30/63aec30b82108.jpg
https://cdn-us.imgs.moe/2022/12/30/63aec30b7fc08.jpg

Other buttons in "more" submenu (out of this topic):
subseribe to page, print, add a search engine, view page source. logins, character encoding.

(In reply to Calixte Denizet (:calixte) from comment #11)

I suppose that the users would like to have a button in the 3-dots menu or something like that.

In my opinion, I don't think so. When a user clicks a download link or button for a PDF on a website, it doesn't make much sense for Firefox to open it and then needing go into the 3-dots menu to download what I previously could download immediately. Even if the current way to download a PDF is moved out of the share menu, it's still not very intuitive in my opinion.
Personally, I think it'd be best if the user would get prompted with the question to download it directly like before, but with the added button to view it (with a download option somewhere).

When a user clicks a download link or button for a PDF on a website, it doesn't make much sense for Firefox to open it

That's what desktop Firefox does, right?

(In reply to Alexander Browne from comment #15)

That's what desktop Firefox does, right?

Desktop both downloads it and opens it when the download is done.

(In reply to Calixte Denizet (:calixte) from comment #11)

The way to download a pdf is to click on 3-dots button, then share and finally save as PDF.
I suppose that the users would like to have a button in the 3-dots menu or something like that.
I can likely write a patch to add a menu entry somewhere, but I need to know what "somewhere" is, to have an icon and the wording.

This is a Product question for Ethan, who is needinfo'd on this bug. In the meantime, I'll add this question to the UX designers' backlog.

Flags: needinfo?(cpeterson)
Whiteboard: [fxdroid] [experience] [Needs-UX]

The bug is marked as tracked for firefox112 (beta) and tracked for firefox113 (nightly). We have limited time to fix this, the soft freeze is in 3 days. However, the bug still isn't assigned.

:cpeterson, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit auto_nag documentation.

Flags: needinfo?(cpeterson)
Component: General → PDF Viewer
Flags: needinfo?(cpeterson)
Product: Fenix → Firefox

Ethan says he's not the PM for PDF integration. Ania will reply instead.

Flags: needinfo?(epiper) → needinfo?(asafko)

Removing release tracking. This bug is on the Android Experience team's backlog.

Whiteboard: [fxdroid] [experience] [Needs-UX] → [fxdroid] [foundation] [Needs-UX]

(Updating the summary because it's sort of confusing this lives in a desktop-focused bugzilla product, but is about a mobile UX question. It doesn't look like there's a PDF-specific Fenix component, but perhaps there should be, or perhaps the bug could be moved to Fenix :: General, given that's where people are suggesting the solution should be found.)

Summary: Downloading PDFs is unintuitive → Downloading PDFs is unintuitive on android

FYI for watchers: we're looking into this issue in Fenix, but we don't have a solid decision about what solution we're going to go with just yet. There have been some internal conversations about rolling back the ViewPDF feature entirely to address these concerns, but I'm trying to encourage the team to find a simple improvement so we don't have to do that. Not sure yet where the fix will live (PDF.js, GeckoView, or Fenix) but for now, I'm going to migrate this to Fenix::General for tracking purposes.

More info to come - we have engineering, UX, and product looking into this actively already.

Severity: -- → S3
Component: PDF Viewer → General
Priority: -- → P1
Product: Firefox → Fenix
Version: unspecified → Firefox 112

some suggestions:
This also happens when you click a button and get send to a get page serving base64.
The button on the web page displayed a download icon. According to stackoverview base64 is/was one save way for webservers to initiate a download not viewing.
If this gets fixed, then I'd like to see the user asked immediately whether he/she wants to download the file (usual pop up at the bottom of the screen), while the pdf is displayed in the background. They can still cancel the download to view the file instead :)

When a pdf is accessible via link instead of a button then I was able to save from the previous page by using "save page" in the context menu of the link, which isn't possible for buttons obviously.
I was never thinking about using the share menu, because I don't want to share the file with anyone, just access it later and have it saved. (it's a ticket)

also something I noticed: When I close the tab and then click undo: it opens the empty page and then opens a new tab to display the base64 pdf. Simple reloading (for the same reason) practically duplicates the tab ^^ (the old tab keeps on displaying the base64 pdf)

(In reply to Joe M [:jmahon] from comment #22)

FYI for watchers: we're looking into this issue in Fenix, but we don't have a solid decision about what solution we're going to go with just yet. There have been some internal conversations about rolling back the ViewPDF feature entirely to address these concerns, but I'm trying to encourage the team to find a simple improvement so we don't have to do that. Not sure yet where the fix will live (PDF.js, GeckoView, or Fenix) but for now, I'm going to migrate this to Fenix::General for tracking purposes.

More info to come - we have engineering, UX, and product looking into this actively already.

I believe it would be easy on the pdf.js side to add a simple overlay button in the bottom right corner of the screen. Calixte, could you confirm?

This bug also makes me think that the "Save as PDF" feature too (for normal web pages I mean) might not be so discoverable. I have always had this feeling, and this further confirms it. Do we have any statistics on how often people use "Save as PDF"? Should we consider adding a menu item to save pages (html or PDF) as PDF?

Flags: needinfo?(cdenizet)

Thanks for the additional info, Marco!

Should we consider adding a menu item to save pages (html or PDF) as PDF?

That's definitely something we should investigate, but FWIW our menu is already longer than we'd like it to be. I'll let the UX team make that call, though - I know the content design team is already evaluating ideas to clean up our existing menu; so maybe they can take a closer look at the "Save as PDF" impressions as part of that project. We have telemetry for that, so should be pretty easy to figure out how often people use it - what might be more challenging is figuring out how often people go looking for it and fail to find it!

I'll add a button to download the file in the pdf.js UI.
It'll require to add some new api in the GV side in order to handle the event triggered by clicking on it.

Assignee: nobody → cdenizet
Status: NEW → ASSIGNED
Flags: needinfo?(cdenizet)

The mobile PMs discussed the problem and Calixte has a solution.

Flags: needinfo?(asafko)
Pushed by cdenizet@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/bd531e61e853
Add an event GeckoView:SavePdf in order to be able save a pdf from the pdf.js UI r=geckoview-reviewers,pdfjs-reviewers,marco,m_kato

Thank you Calixte for working this.

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 114 Branch

The patch landed in nightly and beta is affected.
:calixte, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox113 to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(cdenizet)
No longer depends on: 1827474

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #36)

The patch landed in nightly and beta is affected.
:calixte, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox113 to wontfix.

Android engineering manager Bryan Clark says we don't need to uplift this fix to 113.

Flags: needinfo?(cdenizet)

Comment on attachment 9327563 [details]
Bug 1823164 - Add an event GeckoView:SavePdf in order to be able save a pdf from the pdf.js UI r=#geckoview-reviewers,#pdfjs-reviewers

Beta/Release Uplift Approval Request

  • User impact if declined: Downloading PDFs is unintutive on Android when inside the viewer. This patch contains the GeckoView API necessary for PDF.js to connect to for downloading PDFs. This patch does not contain user facing UI elements.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This patch has the GeckoView API for downloading PDFs for PDF.js to use. It does not have any UI changes. To fully uplift the PDF.js changes, this patch is a prerequisite.
  • String changes made/needed:
  • Is Android affected?: Yes
Attachment #9327563 - Flags: approval-mozilla-beta?

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

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #36)

The patch landed in nightly and beta is affected.
:calixte, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox113 to wontfix.

Android engineering manager Bryan Clark says we don't need to uplift this fix to 113.

Just mentioning an update here for visibility. This comment was originally in response to the FAB PDF.js change. The uplift was not necessary for the FAB. However, PDF.js now needs this GeckoView API to implement the download toolbar changes that is planned for 113 now.

See Also: → 1829366

Comment on attachment 9330229 [details]
Bug 1823164 - Add an event GeckoView:SavePdf in order to be able save a pdf from the pdf.js UI

Thanks for doing the Beta rebase. Glad to see this landing in v113! Approved for 113.0b8.

Attachment #9330229 - Flags: approval-mozilla-beta+
Attachment #9327563 - Flags: approval-mozilla-beta?

Added to the Fx113 beta relnotes, but I'm definitely open to suggestions for improvements to the wording:

UI improvements to the built-in PDF viewer to make it easier to save PDFs directly.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: