OpenFileExternally not reached when following link to external file

[Sorgflat]

SumatraPDF version

• 3.5.2 or cdadfde74471e9b06898e5c1e87edd98b4204597 (2025-07-27)

Describe the bug Clicking a link to a local DWF in a PDF won't open it. Instead a notification "Error loading $PATH.dwf" is shown (possibly in a new window when tabs are not used). The file exists, is readable and (apparently) not restricted by SumatraPDF's policy.

To Reproduce

1. Open PDF with a link to a DWF file (or any file that SumatraPDF would want to open externally).
2. Follow the link.

Expected behavior The file should get opened with its associated program like when double-clicking its icon in the Windows shell.

Files that reproduce the problem Please consider the sample files in the attached open-ext.zip. You can change the link reference in the PDF with a text editor to any file you like. I could reproduce the error with Markdown, E-Mail (EML) and MHT files.

Additional context LoadDocument fails as I would expect, because the file format is not supported. But the next check needs be true in order to get to OpenFileExternally https://github.com/sumatrapdfreader/sumatrapdf/blob/cdadfde74471e9b06898e5c1e87edd98b4204597/src/MainWindow.cpp#L554

Personal Workaround I added the following lines before the call to FindMainWindowByFile to get things working for me for the time being:

    if (str::EndsWithI(fullPath, ".dwf")) {
        LaunchBrowser(fullPath);
        return;
    }

I have not yet understood the code in LinkHandler::LaunchFile fully. How would you go to add this functionality in a consistent way?

[GitHubRulesOK]

paths in pdf are an issue that pdf says ..\Desktop\open-ext.dwf and the file is nowhere near Desktop so navigation up towards root is a security breach as it can then form exploits. Also dwf is not a SumatraPDF format to open so try these 2 in any folder

open-ext.pdf

open-ext.txt

[Sorgflat]

That's not the problem. Links like ..\PDF\some.pdf work as long as SumatraPDF handles them internally. Your example works because .txt is handled by LoadDocument. Change the extension to .md (and the link inside the PDF accordingly) and SumatraPDF fails with the same file.

Don't forget these two files are just to state my case. Actually I have a lot more PDF files that link to drawings in DWF format and I cannot just go changing all their links obviously ^^ Also DWF not being a format understood by SumatraPDF is just the point. The question is how SumatraPDF is supposed to handle links to files that need to be opened in another program?

Currently it looks like it tries to open any file by itself first and only on failing that consults external programs (which is where the security checks are made). This would work for me if there wasn't this check in MainWindow.cpp:554 which for some reason says that the document is indeed loaded (although LoadDocument failed before that) and OpenFileExternally does not need to be tried.

[GitHubRulesOK]

SumatraPDF has aways had a list of supported formats so the same file as TXT is permitted (such as settings.txt as was LOG?) but MD or RTF or HTML whilst, similar plain text with a format of their own were not an acceptable format compared to other plain text files.

FOR example 3.1.2 had to be fiddled to allow for some text formats and even some PDF here is your example which is NOT a valid PDF even though PDF CAN be Plain Text.

Any TXT extension can be read (and some others) and include https:// links same as a PDF file

However, DWF was never a supported text eBook format.

[Sorgflat]

I do not want to open DWF inside of SumatraPDF. Instead a separate viewer should be called for that. Like when the link points to ..\Downloads\Radio.m3u it opens the associated media player via OpenFileExternally.

PS: The check at MainWindow.cpp:554 is only a problem in the latest release. The DWF gets opened in the latest commit, when HKCR\.dwf\PerceivedType:SZ = "webpage" (although there is no sumatrapdfrestrict.ini in place which should allow all file types) and SumatraPDF is not tabbed. Then a new window gets opened with the aforementioned error, but the target DWF gets opened anyway ^^

[GitHubRulesOK]

SumatraPDF is not like Pdf viewers that open linked files. Actions and functions such as running scripts are deliberately avoided. There have been old exploits using simple files even plaintext so MuPDF may offer some methods, but SumatraPDF should not due to increased guards against exploits see https://github.com/sumatrapdfreader/sumatrapdf/issues/605 the most relevant comment is https://github.com/sumatrapdfreader/sumatrapdf/blob/cdadfde74471e9b06898e5c1e87edd98b4204597/src/MainWindow.cpp#L502

There are still some loopholes unplugged but launching external files has been minimised over the years either by MuPDF or its changes to the core code.

The main removal was as a result of https://github.com/sumatrapdfreader/sumatrapdf/issues/1336 but as stated there it was an Adobe optional function.

SOME viewers may launch files but will warn you the script may be an exploit.

Viewers like Acrobat Powered Edge will not launch the linked file. Nor would SumatraPDF 3.1.2

MuPDF viewer cannot run such files although it shows that file as starting on page 1.

To launch such exploits without blockers use Okular