Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PDF viewer doesn't open from mail attachments pane #2

Open
dirkf opened this issue Oct 7, 2019 · 14 comments
Open

PDF viewer doesn't open from mail attachments pane #2

dirkf opened this issue Oct 7, 2019 · 14 comments

Comments

@dirkf
Copy link

dirkf commented Oct 7, 2019

Configuration

SM-2.49.4/5, LXLE 16.04 Linux i686
PDF.js 2.2.253

Steps to reproduce the problem:

  1. Set emails to view as text
  2. Edit>Preferences>Browser>Helper Applications should show "PDF: Always Ask"
  3. Open an email with attached PDF file
  4. Open (double-click or context-menu>Open) the attachment
  5. Nothing happens
  6. Instead try context-menu>Open With...>Document Viewer
  7. 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.

@RainerBielefeld
Copy link

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.

@mike406
Copy link

mike406 commented May 29, 2020

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

@IsaacSchemm
Copy link
Owner

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"?

@mike406
Copy link

mike406 commented Jun 3, 2020

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.

screenshot

@Hardyst
Copy link

Hardyst commented Jun 12, 2020

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

@IsaacSchemm
Copy link
Owner

The code in question was added in commit 3f4f056, 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.

IsaacSchemm added a commit that referenced this issue Jun 19, 2020
@IsaacSchemm
Copy link
Owner

I uploaded a new release here to GitHub. Let me know if it works and I'll submit it to addons.thunderbird.

@dirkf
Copy link
Author

dirkf commented Jun 19, 2020

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.

@mike406
Copy link

mike406 commented Jun 19, 2020

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.

@dirkf
Copy link
Author

dirkf commented Aug 30, 2020

SM 2.53.3, viewer 2.3.235: works for me

@dirkf dirkf closed this as completed Aug 30, 2020
@mike406
Copy link

mike406 commented Sep 1, 2020

Updated to 2.53.3 with viewer 2.3.235, issue still persists

@dirkf
Copy link
Author

dirkf commented Sep 1, 2020

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

@dirkf dirkf reopened this Sep 1, 2020
@mike406
Copy link

mike406 commented Sep 4, 2020

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.

@dirkf
Copy link
Author

dirkf commented Sep 4, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants