pdf.js-seamonkey
pdf.js-seamonkey copied to clipboard
PDF viewer doesn't open from mail attachments pane
Configuration
SM-2.49.4/5, LXLE 16.04 Linux i686 PDF.js 2.2.253
Steps to reproduce the problem:
- Set emails to view as text
- Edit>Preferences>Browser>Helper Applications should show "PDF: Always Ask"
- Open an email with attached PDF file
- Open (double-click or context-menu>Open) the attachment
- Nothing happens
- Instead try context-menu>Open With...>Document Viewer
- The attached file opens in Document Viewer.
What is the expected behaviour?
At step 5, a browser tab with a pdf.js view of the attached file should open.
What went wrong?
There's an invalid assumption in PdfstreamConversion.jsm. When step 5 fails, the Error Console fingers this fragment (lines 941...)
aRequest.QueryInterface(Ci.nsIChannel);
/*943*/ aRequest.QueryInterface(Ci.nsIWritablePropertyBag);
var contentDispositionFilename;
try {
contentDispositionFilename = aRequest.contentDispositionFilename;
} catch (e) {}
// Change the content type so we don't get stuck in a loop.
/*951*/ aRequest.setProperty("contentType", aRequest.contentType);
aRequest.contentType = "text/html";
Line 943 fails (and the viewer then fails to open) because aRequest
in this context doesn't support the nsIWritablePropertyBag
interface, as logged in the Console.
However line 951 expects that it does. If both lines are removed, the viewer works as expected, despite the comment above: not just in the test case, but generally. I couldn't find any code in the viewer that might retrieve the contentType
stashed at line 951.
PDF Viewer 2.2.255 with unzipped unofficial (by wg9s) De SeaMonkey 2.53.1 (NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 Build 20191207130010 (Default Classic Theme) on German WIN7 64bit: Opens PDF Viewer TAB after doubleclick on attachment.pdf, but needs a click on "Refresh Page" icon in navigator navigation pane before it will show PDF contents.
I have a really hacky solution to this (using the unofficial patched PDF viewer by frg https://unofficialseamonkeynews.wordpress.com/2019/12/08/pdf-viewer-pdf-js-for-seamonkey-2-53-1/) (I haven't noticed side effects yet). Basically it's simple, just auto-reload the viewer one time when a PDF is opened. I placed this code at the top of the "viewer.js" in content/web.
if (!localStorage.getItem("reload")) {
localStorage.setItem("reload", "true");
location.reload();
}
else {
localStorage.removeItem("reload");
}
Edit: Also appears to work with release 2.2.255
I actually still can't get it to load from the attachments pane after all. Granted, I haven't tried very hard. But I'm cool with putting this fix in, if it helps. Did you put it right after the "use strict"?
I ended up modifying the viewer.js that is in the bundled .xpi and put it at the top of that script. I wasn't sure where in the source code to put it though.
As a workaround you can set the link behavior to "Open in new Window" then you do not need to reload. See also https://www.hst-pc.de/seamonkey-pdf-viewer
The code in question was added in commit 3f4f056665b1bdc2b4a2b9aaf65f8783613442ee, apparently to provide save as support in Firefox back in 2013. SeaMonkey seems to work just fine without it. I'll take those two lines out.
I uploaded a new release here to GitHub. Let me know if it works and I'll submit it to addons.thunderbird.
Works for me SeaMonkey 2.49.5, LXLE 16.04 Linux i686.
Incidentally the pdf.js save icon works fine. The browser's File>Save Page As... saves a .mht version of the page (including pdf.js) with a .pdf extension; it doesn't cache the actual PDF file with the page assets, but I didn't really expect it to.
In Preferences>Link Behaviour I have buttons (2,1,3) = (new tab,always tabs,new window), whereas 2.53 needs (*,2,*) = (*,Don't divert custom windows into tabs,*), according to other reports.
Tested on SeaMonkey 2.53.2 - issue still persists where a manual page refresh is required to get PDFs to display when opened through the Mail attachment pane.
SM 2.53.3, viewer 2.3.235: works for me
Updated to 2.53.3 with viewer 2.3.235, issue still persists
Mike, there must be some difference in config. You haven't revealed your platform yet.
Contrary to reports, I didn't have to change Preferences>Link Behaviour from buttons (2,1,3) = (new tab,always tabs,new window).
It is on Win 10 x64, with Link Behavior set to 2,2,2 = new tab, don't divert, new tab. If I switch it to 2,1,3 like you have suggested it does work when the PDF attachment opens in a new window.
OK, I see the same behaviour as you with 2,2,2, and with 2,1,2 and 2,3,2 ad 2,3,1, but not with 2,2,3, so it's only working with 'Open links from other applications'='New Window'.
So there's some difference between starting the viewer in a new window vs in a SM tab, but presumably this isn't the case in the version of FF on which our host's original fork was targeted.