SDL_OpenURL problems

I can open a website using this command (e.g. SDL_OpenURL(“doc.html”)), but I cannot navigate to a certain part of the document (e.g. via “doc.html#chapter”). Is this a bug or am I missing something?

1 Like

At least on Linux it works should works when using SDL_OpenURL("file:///full/path/to/doc.html#chapter");
The URL is just passed to xdg-open as it is (in a shell), and xdg-open apparently doesn’t like bla.html#foo unless it’s already explicitly told that it’s a file (and xdg-open file:///path only seems to work with full paths, not with relative ones)

Maybe it is a Windows problem? I tried using"file:///" but that didn’t change anything.

That’s possible.
You could toy around with calling open with different arguments in cmd.exe (Windows Command Prompt) to find out what it supports (on Windows SDL_OpenURL() seems to call open with the URL)
Ok, I think I misunderstood the meaning of ShellExecuteW(NULL, L"open", wurl, NULL, NULL, SW_SHOWNORMAL); - apparently it doesn’t run open $wurl in a shell, "open" isn’t a program but a “verb” of ShellExecute(), and the next argument must be a “file or folder”, so adding #chapter will most probably not work.
See also https://docs.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutea

1 Like

Thanks.

That would be too bad, as I wanted to open a help file at the correct position. I had waited for SDL_OpenURL, and now it seems like it doesn’t work as expected. :frowning:

Don’t take that too literally. A URL is fine, so long as all the encoding rules are followed (such as percent-encoding non-allowed characters). I’ve also confirmed that here (Windows 10) a #tag does work as expected. So I can’t see anything wrong with the implementation of SDL_OpenURL() that would explain the OP’s issue.

Thanks for the info. So I must be doing something wrong.

Any idea where I should look for my mistakes?

BTW: It works with websites (“https://…”) but not with local files (“file:///…”). And it is not the website, I downloaded a Wikipedia article and tested with it. The addressbar always removes the “#tag”. Tested with Firefox and Vivaldi, Windows 10

Are you sure this really works, including preserving the anchor?
According to https://stackoverflow.com/a/26305323/14633188 this at least was broken in the past (anchor was stripped)

OTOH, if it doesn’t open your html at all, something else must be going wrong.
What exact string did you pass to SDL_OpenURL()?

It opens the URL, just doesn’t do the navigation to the anchor (which is removed in the addressbar).

Ok, so that bug still persists in Windows.
SDL could try the workaround mentioned at Stackoverflow (get the standard browser and call that directly), but then it’d also have to figure out first if the given URL should really be opened in the browser (as far as I understand SDL_OpenURL() is supposed to be able to open any kind of file in an appropriate program, as far as the standard opening mechanisms of the OS support that).
OTOH, maybe it’s not that difficult: If it starts with http:// or https:// open it in the browser, otherwise, if it contains .htm or .html after the last (back)slash also open it in the browser, otherwise just throw it at ShellExecute() with “open” like before - does that work well enough? Other (pseudo) file-endings for HTML pages like none at all or .php are only expected to open in a browser when served from a webserver, right? (And in that case the URL starts with https?:// and not file://)

I’ve not tried it with files. If it was me, I’d probably host a simple web server on the PC which would provide access to the file using http:// protocol!

That’s above my knowledge. That’s why I was waiting for something simple like an SDL function. :smiley:

Integrating a webserver in your game just to work around windows broken URL handling seems a bit overkill to me.

BTW: The app I am developing for has to work under Windows, macOS and Linux.

A minimal web server is only a few lines of code (in my application I already link with SDL2_net).