Loading error no longer leaves file open

[miloush]

Up to v3.1.2:

Since v3.2:

The difference is that previously, the file was open (and had its own tab if tabs are enabled) and therefore several commands were available, most importantly "Open in Adobe Reader". So when SumatraPDF is your default PDF reader, you open a PDF file that is only compatible with Adobe Reader (say from temporary internet files), you can proceed with re-opening it in Adobe Reader. This is now incredibly much more difficult.

Furthermore, when opening several files at once, you could see which ones were invalid, while now when tabs are enabled, the error messages just fly through and disappear and you cannot read anything.

I suggest the previous behavior to be restored and files that have loading errors stay open/having their tab.

("Show in Folder" should also work for such files)

[GitHubRulesOK]

I have to do some serious damage to a PDF to not see a poor one

However you should be able to send that to Acrobat if it is a PDF whichever interface is active

[miloush]

You could just try to open non-PDF file to test this :)

Hm, none of those options are available to me:

But also I can see in your screenshot that the files do get opened for you (you get tabs and in the second case you have the error inside the window, apart from the notification). Maybe your loading fails later than for my files.

[GitHubRulesOK]

There are several things to consider so

• My Acrobat is installed in registry so SumatraPDF will Automatically find it but that may not always be the case
• My Version is Current 3.5 Pre-Release since that is the only version that can be changed, there can be no changes to 3.4.6
• The cause of a file type fail loading may change for different file contents or locations

[miloush]

The v3.1.2 is happy with letting me open the same file on the same machine in Adobe Reader:

The files I have to open are encrypted and protected by the FileOpen plugin. You can try on the test file they provide, installcomplete.pdf.

(If you prefer getting it directly from the source, there is a link under the first FAQ entry at https://www.fileopen.com/products/troubleshooting-faq). I can reproduce the reported difference in behavior using this file.

[miloush]

I think your test file is good enough to make it to WndProcCanvasLoadError, which is not my case. My case seems to behave the same way as when you try to open a docx/zip file for example.

[GitHubRulesOK]

Thats not a PDF but an Adobe Custom installer so loads other applications (SumatraPDF will not do that) Here we can see the "PDF" is not recognisable as such (Much like JS enabled AI files or XFA which is XML Wolf in a PDF sheepskin) If I open in Acrobat it highjacks my Browser to open a foreign site in MS Edge (that should not be allowed as its a security exploit). Anyway SumatraPDF will clearly open those Tabs that are allowed even the Bad one then finaly show last failed attempt to be exploited.

[miloush]

Yes, and my point is that files which are "PDFs not recognisable as such" opened in tabs/windows of SumatraPDF before and it allowed them to be reopened in Adobe Reader, while since v3.2 that is no longer the case.

[GitHubRulesOK]

Ok I see your point since there is no loaded file object (per the error) there is nothing valid to pass on in that case. However that is not what "Open In" was designed to do. If it was as you suggest (possibly correctly) a by-products of legacy behaviour it was more by accident than design.

[miloush]

As far as I can tell it is actually a valid PDF using Security Handler specified in the Filter entry as per the PDF specification. Adobe Acrobat checks online what to do with that Filter value and gets sent to the webpage that it opens, so not really a security exploit.

I didn't want to make this too complicated, but it sounds like it would be reasonable to detect when a file uses unknown Filter and offer opening it in Acrobat if installed. I just thought it would be easier to not care and always open the file with an error in the canvas.

That way you also avoid users not seeing the error notification when it is replaced with another one or disappears too quickly.

[miloush]

I am guessing this commit https://github.com/sumatrapdfreader/sumatrapdf/commit/b247508908c07bbb5bdad0c4f5c4b5f5929e885d broke it by returning early, skipping the call to what used to be LoadDocIntoCurrentTab. It looks like fixing these issues would practically mean reverting this commit, which I am happy to make PR for, but perhaps @kjk had a reason for it?

[GitHubRulesOK]

@kjk is this regression an easy detection like xfa ? the error condition seems to block using the file option to pass to an external handler (exotic PDFs need to be passed to Adobe Readers.) and secondary issue is that a sidebar issue that favorites is not initiated ? when the error message is dismissed it should but does not look like this

it produces this result

[kjk]

yeah, that's not trivial to fix

[kpym]

It would be helpful to have the ability to send an error report for "Error loading ..." issues.

In my case, I received a Google invoice (a supposedly valid PDF) that can't be opened with Sumatra but works fine in Chrome and Edge. However, I couldn't find a way to send an error report for you to investigate the issue. (I cannot share the PDF here as it contains sensitive information.)

[GitHubRulesOK]

@kpym I see many different problem PDFs each day some are accepted by all readers some by a few some by none. So there is no easy way to tell why a fault is allowed in one application and not another, unless by tracing the behaviour, often in reverse from the faulty behaviour "observed". Many will be faulty without observed misbehaviour.

This tread really is about handling an erroneous file before opening a valid received file so a very tricky open issue.

For SumatraPDF to handle a generic fault. Such as font or truncation or many other "fault groups" a sample is needed for tracing where the "fail" is triggered. And thus the only "private" option is you email the developer [email protected]

For one common means to try a simplified "fix" in some cases open a PDF in Acrobat Reader MAY trigger its editor into adjusting the file and then on closure it will ask if you want to save the changes (fixes). This is the simplest way I know apart from a dedicated re write of rogue contents. Which is NOT "save as" in a browser since that usually just preserves any faults.

A common means to regenerate a PDF is to simply pass through GhostScript (which will attempt to restructure fonts) and check there were no known losses. roughly GSWIN##C -sDEVICE=pdfwrite -oOut.pdf -f In .pdf or more compatible MuTool Clean -gg in.pdf -o out.pdf

[kpym]

Thanks @GitHubRulesOK for your answer.

For SumatraPDF to handle a generic fault. Such as font or truncation or many other "fault groups" a sample is needed for tracing where the "fail" is triggered. And thus the only "private" option is you email the developer [email protected]

I'll send my PDF to this email, but I think that for this project it will be nice if in case of this kind of errors we can generate and send a report directly from Sumatra.

For one common means to try a simplified "fix" in some cases open a PDF in Acrobat Reader MAY trigger its editor into adjusting the file and then on closure it will ask if you want to save the changes (fixes). This is the simplest way I know apart from a dedicated re write of rogue contents. Which is NOT "save as" in a browser since that usually just preserves any faults.

A common means to regenerate a PDF is to simply pass through GhostScript (which will attempt to restructure fonts) and check there were no known losses. roughly GSWIN##C -sDEVICE=pdfwrite -oOut.pdf -f In .pdf or more compatible MuTool Clean -gg in.pdf -o out.pdf

I know how to clean a PDF, thanks. If I write here is to try to make Sumatra better, not just to solve my problem ;)