PDF viewer can’t open attachments that are PDFs
Categories
(Firefox :: PDF Viewer, defect)
Tracking
()
People
(Reporter: me, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0
Steps to reproduce:
-
Open a PDF that contains an attachment that is a PDF. A couple of examples: https://www.jeffersonscher.com/temp/Links-attachments-PDFs.pdf, https://img.fireden.net/tg/image/1446/29/1446297117123.pdf.
-
Open the pdf.js sidebar, switch to its attachments tab, and click on the attached PDF.
Actual results:
A new tab opens and then immediately closes.
By stepping in the debugger, I find in resource://pdf.js/web/viewer.js, function _bindPdfLink, line 4849 at the time of writing, that it’s calling something like open("blob:resource://pdf.js/9a253773-bd8d-4d21-9fd0-2553803f639c#filename=You%20Found%20the%20Secret%20File!.pdf"), which succeeds in opening the new tab, but then immediately closes it again. (If it had failed and thrown an exception, it would have triggered the “download the file instead” path.)
I note that if I open the blob URL in a new tab manually, the browser does not navigate (as when receiving a 204 response). If I change the URL at all, I get the expected “invalid URL” error, showing that the true blob URL is valid, it’s just not loading pdf.js for it.
Expected results:
The attached document should have opened.
These symptoms approximately match bug 1632644 which was fixed a few months ago, but the precise symptoms seem different (it’s not producing the console log line described there; also the patch that fixed it is still applied), so I think this is a different bug rather than a regression.
|
||
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
||
Comment 2•4 years ago
|
||
These work for me in 81 beta 2 on macOS. Can you clarify what version you tested (comment #0 says 81 but 82 is selected in the version field), and if you tried a clean profile? I wonder if it's related to a setting that's enabled on nightly but not elsewhere, or perhaps fission or some other change in your default profile...
|
Reporter | |
Comment 3•4 years ago
|
||
The reason for the 81/82 mismatch is that I started writing the bug report on Nightly at 81 just before the 82 branch, but then updated the browser to 82 and confirmed the bug was still apparent, but it seems form value saving kept the user-agent at the old value.
After experimentation aided by a blank profile, I found the culprit to be an EasyList filter in uBlock Origin, and have filed https://github.com/uBlockOrigin/uAssets/issues/7838. Sorry for not doing due diligence there! I’m still confused why opening the blob URL directly and not in a popup isn’t working, because as far as I can tell uBlock Origin isn’t messing with that, but I’m going to let that go.
|
|
||
Comment 4•4 years ago
|
||
(In reply to Chris Morgan from comment #3)
No need to apologize, and thank you for checking and getting back to us so quickly!
I’m still confused why opening the blob URL directly and not in a popup isn’t working, because as far as I can tell uBlock Origin isn’t messing with that, but I’m going to let that go.
I suspect this is to do with how blob URL data is shared across processes... I think this might become better with Fission (as there'll then be a tighter connection between what child process URLs open in, and their associated origins), but I'm not 100% sure. We have had some other bugs on file around this, I think, e.g. bug 1626573 . It sounds like maybe there's still some gaps around this? It's possible this has to do with how PDF.js creates the internal blob URL... but either way, the blob URL isn't normally exposed and so we're probably unlikely to have time to fix a bug along the lines of "if I go into a debugger and manually extract this blob URL from Firefox's internals..."
All that said... I'm surprised uBlock can interfere with the blob URLs. Like, at all. They're Firefox internals, and they've got a resource://pdf.js principal, from the looks of the URL. :zombie, do you know if that's intentional? (see rest of comment #3)
|
||
Comment 5•4 years ago
|
||
It looks like uBO is just closing the opened popup, not actually "interfering" with the Blob URI. We don't have restrictions on which tabs tabs.remove can close, since that would make tab management extensions impractical. So I would say yes, working as expected.
|
|
||
Comment 6•4 years ago
|
||
I’m still confused why opening the blob URL directly and not in a popup isn’t working, because as far as I can tell uBlock Origin isn’t messing with that, but I’m going to let that go.
Oh, and I think this might be bug 1658878, though I didn't investigate the details.
Description
•