Opening web links in the default browser fails silently in a terminal only environment #91

New Issue

asdf · 2019-11-14T12:12:48Z

asdf commented

2019-11-14 12:12:48 +00:00

This is actually the same problem as seen in #49. I'm raising it again because:

the behaviour can still happen if the client is misconfigured
if anyone else experiences the issue, this will explain why in more detail
maybe there is something that can be done, but if not we should document it

This issue is non urgent, has low impact, and is a very long story (sorry about that).

The issue occurs when Bombadillo is being run in a terminal-only environment, and the client is configured to open links in the user's default web browser. When opening a web link, the message "Attempting to open in web browser" is shown but no other action occurs.

This behaviour was explained in #49 - the subprocess for xdg-open is started but there's no way for the process to appear on the screen. Also, because it is "working", no error is detected or returned.

The workaround was to implement a terminal-based browsing system, which has been proven to be very cool. Further mitigation will also be done in the proposed webmode setting by labelling the option as gui or something similar.

As mentioned, the behaviour can still occur in the described situation. There are some additional items which make this seem a little worse:

the xdg-open process starts, but is marked as 'defunct'
each time you attempt to open a link, another defunct process is created, which hangs around until you exit Bombadillo
The xdg-open man page states that it is for use inside a desktop session only

Maybe there is a way to handle this nicely - detect a defunct process, identify the environment, or execute the command a different way. In this case, a nice error could be returned.

I can't see an uncomplicated, obvious, or non-hacky way to deal with this. I suspect this will just have to be clearly documented, and in this case it would be more than acceptable (imho).

This is actually the same problem as seen in #49. I'm raising it again because: - the behaviour can still happen if the client is misconfigured - if anyone else experiences the issue, this will explain why in more detail - maybe there is something that can be done, but if not we should document it This issue is non urgent, has low impact, and is a very long story (sorry about that). The issue occurs when Bombadillo is being run in a terminal-only environment, and the client is configured to open links in the user's default web browser. When opening a web link, the message "Attempting to open in web browser" is shown but no other action occurs. This behaviour was explained in #49 - the subprocess for `xdg-open` is started but there's no way for the process to appear on the screen. Also, because it is "working", no error is detected or returned. The workaround was to implement a terminal-based browsing system, which has been proven to be very cool. Further mitigation will also be done in the proposed `webmode` setting by labelling the option as `gui` or something similar. As mentioned, the behaviour can still occur in the described situation. There are some additional items which make this seem a little worse: - the `xdg-open` process starts, but is marked as 'defunct' - each time you attempt to open a link, another defunct process is created, which hangs around until you exit Bombadillo - The `xdg-open` man page states that it is for use inside a desktop session only Maybe there is a way to handle this nicely - detect a defunct process, identify the environment, or execute the command a different way. In this case, a nice error could be returned. I can't see an uncomplicated, obvious, or non-hacky way to deal with this. I suspect this will just have to be clearly documented, and in this case it would be more than acceptable (imho).

asdf added the

duplicate

non-urgent

http

labels 2019-11-14 12:12:48 +00:00

sloum commented

2019-11-14 14:49:12 +00:00

The only way I can figure would be some form of X (x windows) detection. But that only works on a system running x (which should be the vast majority I believe). I'm not sure how to do that.... but if it is doable, we could catch this before sending to xdg-open.

sloum commented

2019-11-14 18:18:42 +00:00

This is partially addressed by #92 (I go into detail there, but the brief version is that a check for Xorg is made. If the check errors then messaging is returned to the user rather than trying to open in a browser).

This is partially addressed by #92 (I go into detail there, but the brief version is that a check for `Xorg` is made. If the check errors then messaging is returned to the user rather than trying to open in a browser).

asdf referenced this issue

2019-11-15 00:47:59 +00:00

Adds different web backends and cleans up options #92

asdf commented

2019-11-15 01:21:14 +00:00

There is another rare situation where this issue could appear. This bug talks about using xdg-open in a graphical environment, but having it open a terminal application that results in the exact same behaviour.

This situation has a workaround. It is not a problem with Bombadillo or the way we are using xdg-open, so is not something we should address. Furthermore, I don't think the direction of #92 should be changed by this new information.

There is another rare situation where this issue could appear. [This bug](https://gitlab.freedesktop.org/xdg/xdg-utils/issues/84) talks about using `xdg-open` in a graphical environment, but having it open a terminal application that results in the exact same behaviour. This situation has a [workaround](https://unix.stackexchange.com/questions/257158/change-default-web-browser-to-lynx-from-terminal). It is not a problem with Bombadillo or the way we are using `xdg-open`, so is not something we should address. Furthermore, I don't think the direction of #92 should be changed by this new information.

sloum commented

2019-11-15 03:41:02 +00:00

Wow. That issue and the workaround are both pretty cool. I did not know that was even possible. Really neat. Agreed not something to worry about re: #92

It does bring up the interesting side-quest of bombadillo.desktop. If one was created and added as part of the isntall/makefile process then searching for applications in gnome, for example, would show bombadillo as a result. We could even make an icon and folks could put bombadillo on their launcher/bar/tray/menu/whatever. I had not thought about doing so, having been concerned with other things... but it has some appeal.

Wow. That issue and the workaround are both pretty cool. I did not know that was even possible. Really neat. Agreed not something to worry about re: #92 It does bring up the interesting side-quest of `bombadillo.desktop`. If one was created and added as part of the isntall/makefile process then searching for applications in gnome, for example, would show bombadillo as a result. We could even make an icon and folks could put bombadillo on their launcher/bar/tray/menu/whatever. I had not thought about doing so, having been concerned with other things... but it has some appeal.

asdf commented

2019-11-15 04:25:53 +00:00

That is a really good idea. It could be a default handler for gopher and gemini links.

sloum commented

2019-11-15 04:38:04 +00:00

I have a branch started for this, but need to work on it a bit more. I'll let you know (or you'll see a PR) once it is ~ready.

asdf commented

2019-11-15 05:32:01 +00:00

This issue is mitigated by checking $DISPLAY, $WAYLAND_DISPLAY, and the presence of an Xorg binary on the system. This determines if a GUI environment is available, and from there the appropriate steps to either try xdg-open or return an error message.

Fixed in #92 !

This issue is mitigated by checking $DISPLAY, $WAYLAND_DISPLAY, and the presence of an `Xorg` binary on the system. This determines if a GUI environment is available, and from there the appropriate steps to either try `xdg-open` or return an error message. Fixed in #92 !

🎉 1

asdf closed this issue

2019-11-15 05:32:02 +00:00

Sign in to join this conversation.