Print button doesn't respond on PDFs opened from Matrix chats
Categories
(Firefox :: PDF Viewer, defect, P1)
Tracking
()
People
(Reporter: marco, Assigned: calixte)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
STR:
- Send a PDF in a Matrix chat
- Click on it to open it in a new tab
- Try to print the PDF from the pdf.js UI
Nothing happens, and the following message is logged to the console:
Warning: Invalid absolute docBaseUrl: "blob:null/9077c2c5-308a-4a82-9a67-7f26582f90e5".
Printing from the Firefox menu works correctly.
Reporter | ||
Comment 1•2 years ago
|
||
I found https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ff375ced41f5e49d7a30ee1f59dcf7f52b7b469c&tochange=38697602446fd8cb367d8b25078c99b8d3313562 with mozregression. I imagine it is bug 1742648.
Comment 2•2 years ago
|
||
Set release status flags based on info from the regressing bug 1742648
Comment 3•2 years ago
|
||
:enndeakin, since you are the author of the regressor, bug 1742648, could you take a look?
For more information, please visit auto_nag documentation.
Comment 4•2 years ago
|
||
Works OK for me on a simple pdf file.
Unlikely to actually be a regression from 1742648 though. Would be useful to know if it still occurs in builds from before bug 1719892.
Reporter | ||
Comment 5•2 years ago
|
||
I run mozregression again, up to the end: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3f2de354e781bab0ff586660b811c243f234d14e&tochange=0ac722cbe7c10c495aad3b4f53df9ebdd915211e.
So it must be a regression from that change.
I will send you the PDF I have, maybe you can reproduce with that one.
Reporter | ||
Comment 6•2 years ago
|
||
What is your nickname on Matrix?
Reporter | ||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 7•2 years ago
|
||
Set release status flags based on info from the regressing bug 1742648
Updated•2 years ago
|
Comment 8•2 years ago
|
||
What is your nickname on Matrix?
In my testing I logged into chat.mozilla.org and I'm guessing it just uses my name 'neil'.
Reporter | ||
Comment 9•2 years ago
|
||
Thanks, I sent you the PDF on Matrix.
After bug 1772569, this is only reproducible after setting browser.download.open_pdf_attachments_inline to true.
Assignee | ||
Updated•2 years ago
|
Reporter | ||
Comment 10•2 years ago
|
||
Moving this to the component of the regressor.
Comment 11•2 years ago
|
||
Marco, we tried but cannot reproduce the bug in current Nightly, could you please try again once you're back? If you can still reproduce, could you please try in a new profile, so we can check if some prefs are involved?
Reporter | ||
Comment 12•2 years ago
|
||
(In reply to Marco Bonardo [:mak] from comment #11)
Marco, we tried but cannot reproduce the bug in current Nightly, could you please try again once you're back? If you can still reproduce, could you please try in a new profile, so we can check if some prefs are involved?
browser.download.open_pdf_attachments_inline needs to be set to true (see comment 9).
Comment 13•2 years ago
|
||
(In reply to Marco Castelluccio [:marco] from comment #12)
browser.download.open_pdf_attachments_inline needs to be set to true (see comment 9).
yes, we did that, but it's not sufficient to reproduce the bug on our side.
Assignee | ||
Comment 14•2 years ago
|
||
I don't know if it's related to Marco's issue, but I noticed that when a pdf is opened from matrix and then if I copy the URL from the new download panel (right click + "Copy Download Link"), I get a blob url with a null principal.
I fixed a similar bug where the url was blob:resource://pdf.js/...
(see bug 1766030).
Comment 15•2 years ago
|
||
Yes, I see the same when copying the url from the panel, but print still works for me.
I'm on Windows 10, I suspect Marco may be on another OS and maybe that makes a difference?
Updated•2 years ago
|
Reporter | ||
Comment 16•2 years ago
|
||
Yes, I can reproduce in a clean Nightly profile after setting browser.download.open_pdf_attachments_inline to true. If you can't reproduce on Windows, maybe this is Linux-only?
Comment 17•2 years ago
|
||
The steps here result in a blob:null/
blob URL for the PDF document, and clicking the button invokes window.print
. But the canvas callbacks that pdfjs tries to use are never invoked, which is presumably why things don't work. I don't know why those callbacks are not invoked, and if there is an issue in PDF.js in not registering them because of the weird URL, or in the print code b0rking because of the weird URL, but either way it's not really a file handling issue. This probably was reproducible before the "regression" window if you did something like this:
- create a sandboxed iframe
- fetch a PDF that has permissive CORS headers with
fetch()
- get the
blob()
of the response window.open()
the blob.- try to print from the PDF.js button in the toolbar of the opened tab.
Assignee | ||
Comment 18•2 years ago
|
||
I think I managed to debug that stuff:
- we're exiting the the print stuff here: https://searchfox.org/mozilla-central/rev/0948667bc62415d48abff27e1405fb4ab4d65d75/dom/base/nsGlobalWindowOuter.cpp#5074
- it's because the
mDoc
hasn't theSANDBOXED_MODALS
flag: https://searchfox.org/mozilla-central/rev/0948667bc62415d48abff27e1405fb4ab4d65d75/dom/base/nsGlobalWindowOuter.cpp#2836 - and this flag is set thanks to
allow-modals
on sandboxed iframe.
After clicking on an attachement, in looking in devtools, I found this iframe:
<iframe style="display: none;" sandbox="allow-scripts allow-downloads allow-downloads-without-user-activation" src="usercontent/">
<head>
<!--
Hello! If you're reading this, perhaps you're wondering what this
file is doing and why your Element is using it.
In short, this allows Element to isolate potentially unsafe encrypted
attachments into their own origin, away from your Element.
Stay curious!
-->
<link rel="preload" href="/fonts/Inter/Inter-BoldItalic.2129bd0.woff2"><link rel="preload" href="/fonts/Inter/Inter-Bold.fc28dff.woff2"><link rel="preload" href="/fonts/Inter/Inter-SemiBoldItalic.10a60d8.woff2"><link rel="preload" href="/fonts/Inter/Inter-SemiBold.0802d48.woff2"><link rel="preload" href="/fonts/Inter/Inter-MediumItalic.8154ac2.woff2"><link rel="preload" href="/fonts/Inter/Inter-Medium.027d14e.woff2"><link rel="preload" href="/fonts/Inter/Inter-Italic.b791861.woff2"><link rel="preload" href="/fonts/Inter/Inter-Regular.4232a67.woff2"></head>
<body style="margin: 0px; overflow: hidden;"><script src="../bundles/0c2c1ac7f0976f797619/usercontent.js"></script>
<a id="a" rel="noreferrer noopener" download="Untitled.pdf" style="font-family: Arial, Helvetica, sans-serif;" href="blob:null/84d0c3d3-fb7e-4df8-98cf-ed1460e11046"><span id="img" style="width: 12px; height: 12px; mask-size: 12px; mask-position: center center; mask-repeat: no-repeat; display: inline-block; mask-image: url("");"></span></a></body>
</iframe>
and if I add allow-modals
in the sandbox
then it works as expected.
Comment 19•2 years ago
|
||
How come printing from the browser UI does work? Does it hit a different code-path?
I guess if we made the Firefox copy of PDF.js hit the same codepath that'd fix the bug...
Assignee | ||
Comment 20•2 years ago
•
|
||
In pdf.js, we print in using window.print
.
If I'm correct, the browser UI is using cmd_print
which isn't calling window.print
:
https://searchfox.org/mozilla-central/source/browser/base/content/browser-sets.inc#31
Assignee | ||
Comment 21•2 years ago
|
||
Why does the newly opened document inherit some properties from the iframe containing the link ?
The pdf isn't really within the iframe so it should be possible to allow the modals or whatever for it.
Comment 22•2 years ago
|
||
(In reply to Calixte Denizet (:calixte) from comment #21)
Why does the newly opened document inherit some properties from the iframe containing the link ?
I haven't checked but if I had to guess, it'd be because the PDF's blob and blob URI are created inside the sandboxed frame, so it inherits the principal (= security properties) from the document creating the blob + blob URI.
(In reply to Calixte Denizet (:calixte) from comment #20)
In pdf.js, we print in using
window.print
.
If I'm correct, the browser UI is usingcmd_print
which isn't callingwindow.print
:
https://searchfox.org/mozilla-central/source/browser/base/content/browser-sets.inc#31
Right, so if we used the messaging infrastructure to tell the parent "hey this doc requested a print" from pdf.js, and then made that do the thing cmd_print
is doing, that would work. That's a doable fix here, right? It would also remove other inconsistencies between the print button and printing from the browser UI for pdf.js - which seems like a very good thing.
Assignee | ||
Updated•2 years ago
|
Reporter | ||
Comment 23•2 years ago
|
||
The sandbox bug probably existed before, but this specific problem started to appear after bug 1742648, so we should still consider it a regression.
Assignee | ||
Comment 24•2 years ago
|
||
Assignee | ||
Comment 25•2 years ago
|
||
Use PrintUtils.startPrintWindow in order to bypass the various checks we can have in using
window.print.
This change makes the pdf printing more consistent with what we have in general.
Comment 26•2 years ago
|
||
Set release status flags based on info from the regressing bug 1742648
Updated•2 years ago
|
Comment 27•2 years ago
|
||
:calixte looks like this was fixed in 107 when Bug 1792052 landed?
Could you confirm if this bug status should be resolved?
Assignee | ||
Comment 28•2 years ago
|
||
No it shouldn't.
The upstream patch has been reverted because I must update the patch in m-c which didn't land.
Updated•2 years ago
|
Updated•2 years ago
|
Description
•