Specifically, with Geany-1.30.1 (default install) on Win7/32-bit, when accessing help from within preferences, help fails to open and the following error is reported in the status bar:
*Failed to open URI: "C:\Program Files\Geany\share\doc\geany\html\index.html#editor-features-preferences": The system cannot find the file specified.*
(The `index.html` file is in that exact location, but it is not being found.)
When opened manually from within IE, the help file opens fine and the URI shown in IE is:
`file:///C:/Program%20Files/Geany/share/doc/geany/html/index.html#editor-features-preferences`
The primary difference being the `file:///` appended to the beginning, but that simply looks to be.how IE reports the URI in the address bar rather than any cause of the failure to open. My only guess is that there is a parse error somewhere, perhaps with the jump reference within the page being tacked on the end of the filename (e.g. `#editor-features-preferences`)
I apologize for initially filing under the different unrelated bug. This is a low-priority issue. Let me know if you need me to provide anything else.
Weird. We explicitly strip the `file://` prefix from the URL when opening URLs on Windows. I don't remember why we did this. Though even when keeping the prefix, the URL opens but the anchor is stripped and ignored.
I'll debug this further at the weekend.
It uses `file:///` for windows, and the skip is only used to test if the file is locally installed or if we have to go to the online `geany.org` copy. It should call `win32_open_browser()` with the `file:///` intact AFAICT.
Same thing with Firefox as default browser. When I run it from the command line with the forward slashes in the path it doesn't realize it's a path and searches the web using the current search provider. With proper backslashes, it tries to open the file, but the `#` for the anchor name gets replaced with `%23` and so it can't find the file called `index.html%23editor-features-preferences`. With a proper URI (ie. with `file:///` and forward slashes) it opens fine from the command line.
Windows support is annoying :(.
@Lex On Windows, we always strip the `file://` prefix in https://github.com/geany/geany/blob/master/src/win32.c#L789. This has been added to support the "builtin" Run command for HTML files, this wouldn't work otherwise. Maybe this just masks another bug in constructing the URI in the "builtin" Run command logic which is pretty much wrong for Windows. However, I don't want to open three new issues two weeks before the release.
@codebrainz Even with a proper URI, it won't open from within Geany as we call `ShellExecute` and this function does not support anchors in the URL (anymore, reports on the net indicate that it worked in Windows XP). The reason we use `ShellExecute("open", uri, ...)` on Windows is that it's the easiest way to open the system's default browser without any hassle. Well, except the hassle with anchors.
I see two ways to proceed here: - quick'n'easy solution: in `win32_open_browser` simply strip off any anchors in the URL - instead of unconditionally use `ShellExecute` on Windows, use the browser command configured in the preferences and maybe fallback to `ShellExecute` in case no browser is configured
I'd prefer the second solution as it seems more reasonable to me, fixes the anchor problem cleanly (already tested) and also would allow the user to choose another browser than the system's default one. Currently, the browser command setting in the preferences is completely ignored on Windows.
@eht16 `@lex` isn't actually my github name, but getting pinged serves them right for using it before I did :) (hope they are friendly)
However, I don't want to open three new issues two weeks before the release.
Its ok to open them, just don't commit windows only fixes the week before release ;-D
I'd prefer the second solution as it seems more reasonable to me
The only issue with it is that it defaults to firefox IIRC, a browser not necessarily installed on windows machines, the `ShellExecute` at least found an installed browser.
The reason we use ShellExecute("open", uri, ...) on Windows is that it's the easiest way to open the system's default browser without any hassle.
Probably before, but since GTK+ 2.14 I think the simplest and most robust way should be [`gtk_show_uri()`](https://developer.gnome.org/gtk3/stable/gtk3-Filesystem-utilities.html#gtk-s...) (or the misdocumented `_on_window()` variant for newer GTK+).
instead of unconditionally use ShellExecute on Windows, use the browser command configured in the preferences and maybe fallback to ShellExecute in case no browser is configured
+1, though I'd fallback on `gtk_show_uri()` if it works OK on Windows (and _then_ maybe fall back to `ShellExecute()` or even `iexplore` or whatever). Also, it should fallback if either the browser isn't configured or if the configured application fails to launch, for example if Firefox isn't installed, as @elextr mentioned.
Yeah, `gtk_show_uri()` should be tested on windows, and tested that it handles the `#foo` correctly for both `file://` and `http://` urls. If it works for GTK2 and 3 then use it if no browser is configured, on all platforms, and on windows don't configure a browser by default (we already have `#if` to select safari instead of firefox for mac, a win one won't hurt)
for both file:// and http:// urls. If it works for GTK2 and 3 then use it if no browser is configured, on all platforms
From the misdocumented functions above:
The uri must be of a form understood by GIO (i.e. you need to install gvfs to get support for uri schemes such as http:// or ftp://, as only local files are handled by GIO itself).
Unless Geany is gonna depend on GVFS, I think it's only useful for local files (or we have to do additonal checking and have a separate fallback).
Yeah the GVFS is a problem, especially for windows. But the GVFS dependency is only for the `_window` version IIUC.
If its only useful for local files its useless, since open browser is used for lots of stuff. But we can use the basic`gtk_show_uri()` version (if it works), until its removed in GTK4 its only deprecated.
I'm going to test `gtk_show_uri()` (and the `_on_window` variant) on Windows, maybe it works for file:// and http:// URIs even without GVFS what should be well enough for opening URLs in the browser.
I would prepare a PR to do the following: - remove the "firefox" default browser on Windows, letting it undefined for Windows - change the behavior to use the configured browser command on Windows for opening URIs - fallback to `gtk_show_uri` if no browser command is configured (or fallback to `ShellExecute` if `gtk_show_uri` does not work) - maybe check for the configured browser command to not equal "firefox" which was the previous default value on Windows which most probably won't work for most users except they added firefox to their $PATH which is unlikely; this would help users with existing configurations
I'm going to test gtk_show_uri() (and the _on_window variant) on Windows, maybe it works for file:// and http:// URIs even without GVFS what should be well enough for opening URLs in the browser.
Great, don't forget to test URLs with `#foo` on them in case GTK just uses `ShellExecute` internally.
The PR sounds great, but I'm not sure about your last point though since it will break firefox for those where it does actually work.
If `gtk_show_uri()` doesn't work, this should do fine to open the default browser:
```c system("start "" "file:///C:/where/ever/foo.html#blah""); ```
At least it works fine from the command line.
I'll stretch the last point from the future PR plan. Maybe we find another solution for existing users or just leave them with their configuration.
WRT `gtk_show_uri()`: for it doesn't work with any local filesystem URL, neither with `file://` prefix nor without nor escaped nor unescaped.
At the end, I got even this: ```20:50:02: Geany WARNING : ShellExecute failed opening "http://www.geany.org": Failed to execute helper program (Invalid argument) ```, i.e. it didn't open a plain and dead simple HTTP uri :(. Based on the error message, I guess it might indeed related to GVFS and its absence on Windows :).
Some time after the release I would work on the above mentioned behavior change to prefer the users' preferences and falling back to the old, slightly broken method.
github-comments@lists.geany.org