STR:

1. Send a PDF in a Matrix chat
2. Click on it to open it in a new tab
3. 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.

I found https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ff375ced41f5e49d7a30ee1f59dcf7f52b7b469c&tochange=38697602446fd8cb367d8b25078c99b8d3313562 with mozregression. I imagine it is bug 1742648.

Set release status flags based on info from the regressing bug 1742648

:enndeakin, since you are the author of the regressor, bug 1742648, could you take a look?
For more information, please visit auto_nag documentation.

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.

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.

What is your nickname on Matrix?

Set release status flags based on info from the regressing bug 1742648

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'.

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.

Moving this to the component of the regressor.

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?

(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).

(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.

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).

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?

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?

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:

1. create a sandboxed iframe
2. fetch a PDF that has permissive CORS headers with fetch()
3. get the blob() of the response
4. window.open() the blob.
5. try to print from the PDF.js button in the toolbar of the opened tab.

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 the SANDBOXED_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(&quot;&quot;);"></span></a></body>
</iframe>

and if I add allow-modals in the sandbox then it works as expected.

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...

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

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.

(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 using cmd_print which isn't calling window.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.

The sandbox bug probably existed before, but this specific problem started to appear after bug 1742648, so we should still consider it a regression.

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.

Set release status flags based on info from the regressing bug 1742648

:calixte looks like this was fixed in 107 when Bug 1792052 landed?
Could you confirm if this bug status should be resolved?

No it shouldn't.
The upstream patch has been reverted because I must update the patch in m-c which didn't land.