Printing a pdf email attachment opens an extra about:blank if you configure opening PDFs to "always ask"
Categories
(Firefox :: File Handling, defect)
Tracking
()
People
(Reporter: neha, Unassigned)
References
Details
(Whiteboard: [print2020_v82][old-ui-])
Attachments
(2 files)
I'm on a Mac, using today's Nightly and trying to print a pdf email attachment opens about:blank before showing the dialog option of opening in firefox or adobe or saving it. In addition, if I choose to open in adobe but then cancel to print, it doesn't cancel the first time and opens up the print dialog again and I have to cancel again.
Even if open in firefox is chosen, that extra blank tab still remains.
I'm attaching screen recordings to show the behavior.
|
Reporter | |
Comment 1•5 years ago
|
||
|
|
Reporter | |
Comment 2•5 years ago
|
||
This is without Fission. And browser console shows
NS_ERROR_FAILURE: Can't use PDF.js
getConvertedType resource://pdf.js/PdfStreamConverter.jsm:1106
|
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 3•5 years ago
|
||
If I print using adobe instead of canceling, then also the print dialog reappears (same as shown in the video for the cancel option), although the document is already printed once.
|
||
Comment 6•5 years ago
|
||
This doesn't seem a regression. Works on a clean profile both on 78 and nightly, and shows about:blank if I set "Always ask" on the preferences.
|
|
||
Comment 7•5 years ago
|
||
I would have expected something like this to reproduce the issue but it doesn't (you see about:blank flash slightly but it closes itself):
<!doctype html>
<button onclick="window.open('http://africau.edu/images/default/sample.pdf', '_blank', 'noopener')">Print an awesome PDF</button>
|
|
||
Comment 8•5 years ago
|
||
So what they're doing is something like this:
<button onclick="window.open('', '_blank', '').location = 'http://africau.edu/images/default/sample.pdf'">Print an awesome PDF</button>
I can confirm that at least the window.open call is exactly with those arguments. Which causes this behavior if you "always ask"...
So this is not totally unexpected given their code. Maybe we can ask them to call window.open() with the PDF url instead?
In any case pretty sure this is not a "Printing" bug...
|
||
Comment 9•5 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)
So this is not totally unexpected given their code. Maybe we can ask them to call window.open() with the PDF url instead?
In any case pretty sure this is not a "Printing" bug...
Perhaps this belongs in Firefox:File Handling then?
|
|
||
Comment 10•5 years ago
|
||
Gijs, maybe you have thoughts on this? I think you've work on some of this stuff recently?
|
||
Comment 11•5 years ago
|
||
I understand that this feels bad from a user's perspective but I don't think there's anything we can do differently.
The website opens a window. At that point we have no idea it's a PDF, so we open a new tab.
Then it loads a PDF into that tab.
The user has configured PDFs to "always ask". Keep in mind that at this point, the browser has no idea that anything is going to want to print. So we ask the user "here's a PDF, what do you want to do?".
Then you pick something, and then presumably google is serving a modified PDF that prompts to print, or something? Like, otherwise, I don't know what triggers the print. This would sort of explain why it tries to print twice in Adobe - there's no way the webpage can talk directly to Adobe, so it can't be the website doing it.
I recommend switching back from "always ask" to "open in Firefox" and moving on. We accidentally switched users on beta and nightly, and that bug (bug 1660277) was caught before 81 has shipped, so this shouldn't, in theory, affect too many release users.
If the pref is set to "always ask", we don't have a way to "not do anything" with the (already loading!) http request until the user makes a decision in the dialog. We have to save the corresponding stream to disk or store the whole thing in memory or whatever - but we can't assume that we could break off the request/response and could make the same one again (and get the same data) - we might not!
So the extant code stores the entire thing on disk, which is why we then open the file from a temp directory once you've made a decision. We can't put that temp file in the about:blank tab because that's web-controlled so google can still navigate it (and, via exceptions, deduce what's happened, sort of), and we can't really know (in the general case) if the web-controlled about:blank page is empty and can be reused for something like loading the PDF (or the prefs, or some other contentful tab).
If we'd opened the tab ourselves or in response to explicit user action (open link in new window or similar) then we could close the tab, but that's not the case here, either - google opened the tab. So the tab stays open.
So I don't think there's anything we can do here. Emilio, can you sanity-check if I'm missing something? If not, I think we should resolve this as invalid. Or, I suppose, we could file a web compat bug and try to convince google docs to do something else here, but I don't know if we'd have a lot of luck with that...
|
|
||
Comment 13•5 years ago
|
||
Gonna resolve per the last few comments.
|
|
Reporter | |
Updated•5 years ago
|
|
||
Comment 14•5 years ago
|
||
I changed chrome to download pdfs instead of opening them in-browser as well (by navigating to chrome://settings/content/pdfDocuments), and could reproduce the same behaviour in Chrome with a blank tab being left open after the PDF is downloaded.
I don't think there's anything we need to do here.
Description
•