Closed Bug 1759083 Opened 3 years ago Closed 3 years ago

Download option in PDF viewer does not present option to "open in"

Categories

(Firefox :: PDF Viewer, defect)

Product:
Firefox
Component:
PDF Viewer
Version:
Firefox 98
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: woolfee9265, Unassigned)

References

Details

(Whiteboard: [pdfjs-ux][pdfjs-ux-wanted])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

Open PDF file using Firefox
Click "download" button in top right corner of FF PDF viewer

Actual results:

Observe that no option to "open in" appears

Expected results:

FF PDF viewer's previous behavior showed a dialogue box where the user could select between "save as" or "open in"

This change in functionality/bug breaks web apps that rely on this feature

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

Component: Untriaged → File Handling

(In reply to Taylor M from comment #1)

This change in functionality/bug breaks web apps that rely on this feature

Can you elaborate? What apps are these and why do they break? If you're already viewing the PDF, why is reopening it locally important - and why is saving to disk and then opening with 1 click from the downloads panel not an option?

Component: File Handling → PDF Viewer
Flags: needinfo?(woolfee9265)
See Also: → 1752149

(In reply to :Gijs (he/him) from comment #3)

(In reply to Taylor M from comment #1)

This change in functionality/bug breaks web apps that rely on this feature

Can you elaborate? What apps are these and why do they break? If you're already viewing the PDF, why is reopening it locally important - and why is saving to disk and then opening with 1 click from the downloads panel not an option?

My existing workflow for sending PDFs by email was to open in a different viewer (Evince) which has a helpful share button that attaches it to an email. Simple 3 clicks to get the email, no thought involved. Now I need to think about where I want to put it temporarily, navigate to that folder, then open the folder from the downloads and try to find the file (often with some long cryptic name). The previous approach put a temporary file in a genuine system temp location which was much better.

To be clear, I do not have default Downloads configured for downloads, because generally downloads are for a purpose, not to dump into some generic flat folder. I almost never want them in the Downloads folder. Even if I did, I'd still have the problem of finding the file in the (now almost certainly heavily populated) Downloads folder.

I suppose another solution to this would be to have firefox have a better option to share the PDF via email (like a "share" button), but this wouldn't solve the problem of misrendering by the PDF viewer (which has certainly been an issue at various points in the past).

All in all, it seems an odd feature to remove.

I was also surprised to see this functionality disappear. My workflow was the following:

  1. Browse scientific papers, opening them in the Firefox PDF viewer.
  2. If an article is interesting and I want to do a more careful reading, open it in an external reader.

I switch to an external reader for a few reasons: it has better performance, it has fewer rendering bugs, it makes better use of screen space with fewer toolbars, and it doesn't crash when Firefox does. I also simply prefer to keep articles I am carefully reading separate from my Web browsing.

why is saving to disk and then opening with 1 click from the downloads panel not an option?

I would prefer to not save to disk, but I suppose that is a different issue. However, with my current settings if I click the entry in the downloads panel, the PDF is again opened in Firefox. Your proposal involves the following clicks:

  1. Left-click on Download button in PDF viewer.
  2. Left-click on Save. (Here I am ignoring the fact that I don't actually want the file saved in my Downloads directory.)
  3. Right-click on the entry in the popped-open downloads panel.
  4. Left-click on open in my chosen external viewer.

If I choose the option to always open in the external viewer, then I can't open PDFs in the Firefox PDF viewer.

Thank you for reporting!

I can confirm the changes in the PDF Viewer on Windows 10 64-bits, macOS 11 and Ubuntu 20.04 on Firefox 100.0 and 101.0, as well as Nightly 102.0a1.

I will set this as New, set the tracking flags and wait for the developer's opinion about it.

Status: UNCONFIRMED → NEW
status-firefox100: --- → affected
status-firefox101: --- → affected
status-firefox102: --- → affected
Ever confirmed: true

Ardelean, could you try using mozregression to identify the change that caused this?

Flags: needinfo?(oana.ardelean)
QA Whiteboard: [qa-regression-triage]

(In reply to Marco Castelluccio [:marco] from comment #7)

Ardelean, could you try using mozregression to identify the change that caused this?

I'm confused, this was a deliberate change. We removed the old code in bug 1757771, which you reviewed.

Flags: needinfo?(oana.ardelean)

Oh sorry I just focused on the last comment by QA and didn't scroll back to see your previous comment. The behavior change isn't from bug 1757771 though, is it? That's just cleaning up code that wasn't used anymore after the download panel improvements work, or did I miss something?

Whiteboard: [pdfjs-ux][pdfjs-ux-wanted]

(In reply to Marco Castelluccio [:marco] from comment #9)

Oh sorry I just focused on the last comment by QA and didn't scroll back to see your previous comment. The behavior change isn't from bug 1757771 though, is it? That's just cleaning up code that wasn't used anymore after the download panel improvements work, or did I miss something?

You're right, but the behaviour change is what obsoleted the code that was then removed in 1757771. Unfortunately the relevant bug wasn't linked and my awesomebar/history results for "pdf download" are such a mess that I couldn't easily find the bug where the code path was changed. Maybe hg blame/annotate is more help at this point...

bug 1740135 is where this changed.

This was in response to discussions with UX, who decided that a "save as" prompt was most appropriate here - the PDF is already being displayed.

IMHO if we wanted to add support to show the PDF in an external viewer then the simplest thing to do would be to have a separate button for that purpose.

Depends on: 1740135

When I enable the "always open with system viewer" all the PDFs get downloaded to my Downloads folder instead of asking me where I want them despite my having "always ask me where to store my downloads".

It works as intended if I let firefox display the PDFs with its pdf.js viewer.

It does not matter if the server sets the header that should force the client into the download dialogue.

(In reply to tuxle from comment #12)

When I enable the "always open with system viewer" all the PDFs get downloaded to my Downloads folder instead of asking me where I want them despite my having "always ask me where to store my downloads".

Yes, this is a consequence of other users requesting that behaviour in bug 1738916, finding it too burdensome to select a location every time a file got opened immediately anyway.

You could have these files go into the tmp dir by using the about:config pref we added in bug 1738574, as of Firefox 102 (released next week).

That behaviour is very distracting especially when I want to download PDFs for university. Currently I can not decide where to store them any more and now I have a folder that contains 5 files called "slides (X).pdf". I would like to undo that change by default and people that want this unpredictable behaviour could then reenable it manually

Flags: needinfo?(woolfee9265)

IMHO if we wanted to add support to show the PDF in an external viewer then the simplest thing to do would be to have a separate button for that purpose.

There is a similar request here:
https://github.com/mozilla/pdf.js/issues/2553

:RT, what do you think ?

Flags: needinfo?(rtestard)

(In reply to cgwg from comment #5)

I was also surprised to see this functionality disappear. My workflow was the following:

  1. Browse scientific papers, opening them in the Firefox PDF viewer.
  2. If an article is interesting and I want to do a more careful reading, open it in an external reader.

I switch to an external reader for a few reasons: it has better performance, it has fewer rendering bugs, it makes better use of screen space with fewer toolbars, and it doesn't crash when Firefox does. I also simply prefer to keep articles I am carefully reading separate from my Web browsing.

I think we should rather fix the underlying issues that prevent you from using Firefox as your only PDF reader. No other PDF reader has buttons or other affordances to let you open PDFs with another reader.
If you see rendering bugs or crashes, feel free to file bugs and we'll take care of them!

(In reply to henry.gomersall from comment #4)

I suppose another solution to this would be to have firefox have a better option to share the PDF via email (like a "share" button), but this wouldn't solve the problem of misrendering by the PDF viewer (which has certainly been an issue at various points in the past).

Misrendering should be very rare now.
The idea of a share button sounds better to me than a "open in" button. Could you file a bug about that? We could perhaps add a share button in the pdf.js overflow menu.

Romain, I'm closing the bug as WONTFIX given my thoughts above, but feel free to reopen if you disagree and think a "open in" button would be useful.

Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(rtestard)
Resolution: --- → WONTFIX

Thanks, I agree with your statement above.
Also worth noting that the tab context menu has a "Share" feature that may be extended in case pdf documents have specific sharing needs

status-firefox104: --- → ?
status-firefox105: --- → ?
status-firefox106: --- → ?
status-firefox-esr102: --- → ?

The other half of the bug that it just downloads all PDFs instead of asking is still not fixed.
It does not even ask where I want to save the PDF to

This bug is about adding a "open in" button. Please open a new, separate, bug about your request.

(In reply to Marco Castelluccio [:marco] from comment #16)

I think we should rather fix the underlying issues that prevent you from using Firefox as your only PDF reader. No other PDF reader has buttons or other affordances to let you open PDFs with another reader.
If you see rendering bugs or crashes, feel free to file bugs and we'll take care of them!

The reasons I want to read PDFs in a separate viewer belong to two categories:

  1. My preferred workflow. Just as I choose to use Thunderbird rather than a website to read/send emails and I choose to use Shotwell rather than a website to view my photos, I also choose to use Atril rather than Firefox to read scientific papers and view plots that I've created. At the same time, Firefox is great for browsing the web and pdf.js is useful for previewing PDFs. Just as I don't want Firefox to immediately load an external viewer for all JPEGs, I also don't want it to immediately load an external viewer for all PDFs; however, I would like an easy way to switch to an external viewer, which existed for several years. I rarely have the need to edit a JPEG, but if I did then I would probably also want a simple way to open a JPEG in an external program. Note that if I left-click on a JPEG from the downloads panel, then it does not open in Firefox, but if I left-click on a PDF it does open in Firefox.

  2. Technical. Firefox's PDF viewer does not have the same performance or quality as external viewers such as those based on Poppler. For instance, this PDF takes about ten seconds to render in Firefox but two seconds in Atril. And when viewed at 50% zoom, Firefox renders the fine lines with far more aliasing than Atril. Obviously this can improve over time, but Poppler provides a good experience now. There are already many performance-related bugs open for the PDF viewer. Would more be useful?

(In reply to cgwg from comment #20)

(In reply to Marco Castelluccio [:marco] from comment #16)

I think we should rather fix the underlying issues that prevent you from using Firefox as your only PDF reader. No other PDF reader has buttons or other affordances to let you open PDFs with another reader.
If you see rendering bugs or crashes, feel free to file bugs and we'll take care of them!

The reasons I want to read PDFs in a separate viewer belong to two categories:

  1. My preferred workflow. Just as I choose to use Thunderbird rather than a website to read/send emails and I choose to use Shotwell rather than a website to view my photos, I also choose to use Atril rather than Firefox to read scientific papers and view plots that I've created. At the same time, Firefox is great for browsing the web and pdf.js is useful for previewing PDFs. Just as I don't want Firefox to immediately load an external viewer for all JPEGs, I also don't want it to immediately load an external viewer for all PDFs; however, I would like an easy way to switch to an external viewer, which existed for several years. I rarely have the need to edit a JPEG, but if I did then I would probably also want a simple way to open a JPEG in an external program. Note that if I left-click on a JPEG from the downloads panel, then it does not open in Firefox, but if I left-click on a PDF it does open in Firefox.

I imagine the preference comes from the point below. If you felt PDF.js had the same or better quality and features as Atril, then you wouldn't need to open PDFs in Atril.

  1. Technical. Firefox's PDF viewer does not have the same performance or quality as external viewers such as those based on Poppler. For instance, this PDF takes about ten seconds to render in Firefox but two seconds in Atril. And when viewed at 50% zoom, Firefox renders the fine lines with far more aliasing than Atril. Obviously this can improve over time, but Poppler provides a good experience now. There are already many performance-related bugs open for the PDF viewer. Would more be useful?

Yes they would be useful. We are focusing on PDF.js quality, so it'd help to know where we are lacking and where we can improve.

Duplicate of this bug: 1763903

(In reply to Marco Castelluccio [:marco] from comment #16)

No other PDF reader has buttons or other affordances to let you open PDFs with another reader.

Actually PDF-XChange does have a button for opening the currently viewed file in some other program, like Adobe Reader.

(In reply to Marco Castelluccio [:marco] from comment #21)

Yes they would be useful. We are focusing on PDF.js quality, so it'd help to know where we are lacking and where we can improve.

I suppose I could dig out some more examples of files that are slow to render, but beyond that I could mainly file dozens of bug reports that'd ultimatively boil down to duplicates of bug 1654612. Ultimately I don't think that'd be that helpful, would it?

And since those problems have persisted for years, I don't have any hopes that there'll be any significant improvements that reduce my need for viewing that kinds of PDFs in an external viewer in the near to mid-term future, either…

(In reply to Jan Henning [:JanH] from comment #23)

(In reply to Marco Castelluccio [:marco] from comment #16)

No other PDF reader has buttons or other affordances to let you open PDFs with another reader.

Actually PDF-XChange does have a button for opening the currently viewed file in some other program, like Adobe Reader.

Interesting, though PDF-XChange is a very specific case and we can't really compare it with much more widespread readers.

(In reply to Marco Castelluccio [:marco] from comment #21)

Yes they would be useful. We are focusing on PDF.js quality, so it'd help to know where we are lacking and where we can improve.

I suppose I could dig out some more examples of files that are slow to render, but beyond that I could mainly file dozens of bug reports that'd ultimatively boil down to duplicates of bug 1654612. Ultimately I don't think that'd be that helpful, would it?

And since those problems have persisted for years, I don't have any hopes that there'll be any significant improvements that reduce my need for viewing that kinds of PDFs in an external viewer in the near to mid-term future, either…

Well, if they all boil down to the same problem, then there is a higher chance we'll fix it (one problem is easier to fix than thousand different ones). If you have cases beyond duplicates of bug 1654612, feel free to file them as bugs, it will be helpful.
The fact that they have persisted for years doesn't mean much, priorities change. Our focus on PDF quality has started recently and we fixed many longstanding bugs.

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