Description of problem: Since Fedora 34, but still an issue in Fedora 35, http(s)-URIs launched via the GIO API don't launch the browser anymore, at least until the calling application terminates. We noticed this since our Java applications cannot launch the default browser using the method `java.awt.Desktop.browse(URI)` anymore, but this also happens when using GIO with other languages, like Python (see reproducible example below). When trying to open an URI using the GIO function `g_app_info_launch_default_for_uri`, nothing will happen until the calling application terminates, which is when the browser will finally open. Until the application terminates, this process can be seen in `ps`: ``` /bin/sh -e -u -c export GIO_LAUNCHED_DESKTOP_FILE_PID=$$; cat <&33; exec "$@" 33<&- sh /usr/bin/chromium-browser https://our_private_keycloak/auth/realms/myrealm/protocol/openid-connect/auth?response_type=code&other_params&scope=openid ``` Only after the calling application terminates the above process will proceed to launch the browser. It doesn't matter if the default browser is Chrome or Firefox. This issue does not happen with upstream glib2 2.70.1 (tested on Arch Linux). I think I was able to track the issue down to this patch: https://src.fedoraproject.org/rpms/glib2/blob/f34/f/0002-gdesktopappinfo-Move-launched-applications-into-tran.patch . Since I am pretty sure that this bug originates from this patch, I am reporting the bug here instead of upstream. Version-Release number of selected component (if applicable): 2.70.1 How reproducible: This issue happens when using the GIO API with any application that does not immediately terminate. Here is how to reproduce this using the python3 console: Steps to Reproduce: 1. `dnf install gobject-introspection-devel` 2. `pip3 install pygobject` 3. Launch a python console using `/usr/bin/python3` and enter the following commands: ``` >>> import gi >>> from gi.repository import Gio >>> Gio.app_info_launch_default_for_uri("https://google.com", None) ``` Actual results: No browser opens until the python console closes (CTRL+D). Expected results: Immediate launch of the default browser.
Another way to reproduce: 1. Open a JShell (`/usr/lib/jvm/java-openjdk/bin/jshell`) 2. Input this command: `java.awt.Desktop.getDesktop().browse(java.net.URI.create("https://google.com"))` The browser will not open until closing the JShell.
As said in the upstream bug report for the MR. The issue is that Gio tries to wait for a response from systemd. This will not be processed without the mainloop being iterated. As such, the workaround is pretty easy, i.e. use the async routine and then iterate the mainloop. import gi from gi.repository import Gio, GLib done=False def cb(*args): global done done = True Gio.app_info_launch_default_for_uri_async("https://google.com", None) while not done: GLib.MainContext.default().iteration(True)
Typo of course, forgot to add the proper parameters for the async call: import gi from gi.repository import Gio, GLib done=False def cb(*args): global done done = True Gio.app_info_launch_default_for_uri_async("https://google.com", None, None, cb) while not done: GLib.MainContext.default().iteration(True)
Of course, this would fix my reproducible example. But this doesn't change that this part of all versions of OpenJDK is currently "broken" with Fedora, and *only* with Fedora. This part of the OpenJDK has not been touched for ages. And I would be surprised if this only affects the OpenJDK. I am even more surprised that no one seems to have noticed this issue for such a long time. Maybe it's an OpenJDK issue after all?
Just for reference: The OpenJDK seems to call the native function `gtk_show_uri`. See: https://github.com/adoptium/jdk11u/blob/73eef16128417f4a489c4dde47383bb4a00f39d4/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c#L206
This is only an issue if you are not running the glib mainloop. Any GTK+ application will do that anyway. So it really should be very rare for it to actually case an issue.
A Java desktop application is (technically) a GTK application. Java uses GTK to draw its GUI on Linux. Sorry that I am not more helpful on this topic. I know next to nothing about GTK, Glib, Gio, DBus... It was already hard enough to track the culprit down to these GLib patches :)
It sounds like OpenJDK expects the application to launch without returning to the main loop. Is that correct? If so, that would be an OpenJDK bug. It's probably already broken in other distros if you try launching an app that uses D-Bus activation, for example. It probably only worked in the past by luck, because your web browser likely doesn't support D-Bus activation. Alternatively, perhaps OpenJDK is misusing a GMainContext somewhere. This can be very hard to debug. I think progress on this issue is unlikely unless the component is reassigned to OpenJDK. OK to do that? You should not need to stop using gtk_show_uri() or the synchronous g_app_info_launch_default_for_uri(), though. That would indicate a GLib bug. Benjamin, any reason you suggested that change? The sync call should not block, right? The application would just not actually launch until later, next time the main loop is iterated.
This is the same discussion we had before. The question is whether g_app_info_launch_default_for_uri should wait long enough for the required DBus communication to be completed. For the DBus activation case, it calls g_dbus_connection_call, which is more of a fire-and-forget call. The difference is that the worker thread will send out the dbus message. So the application will launch without iterating the main context, but e.g. the "launched" callback will not happen. For the systemd case, we do a fork() then we call out to systemd using dbus, and only after the reply is received we allow exec() to proceed. So the MR changes things in the sense that we suddenly need to wait for the DBus response for the application to actually come up. That said, I do feel that using Gio API without ever iterating the mainloop is not really reasonable.
> For the DBus activation case, it calls g_dbus_connection_call, which is more of a fire-and-forget call. The difference is that the worker thread will send out the dbus message. So the application will launch without iterating the main context, but e.g. the "launched" callback will not happen. Ahhh, OK, so that's how it would work for D-Bus activation. Of course, that's still an application bug, unless it's just completely ignoring errors, which could only be reported via the callback that cannot execute. > That said, I do feel that using Gio API without ever iterating the mainloop is not really reasonable. Yeah I agree. I'm going to move this to OpenJDK. I don't think we should change anything here, sorry. It will break in other distros soon enough once the change is upstreamed, then it won't be a Fedora-specific bug anymore and hopefully Java upstream will notice then....
Are we still waiting for the changes to be upstreamed so that other distributions will be affected, too? I am watching https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1596 and it didn't seem like the Merge Request will be merged anytime soon. Until then, this *effectively* continues to be a Fedora-only bug.
I just came across this issue while trying to open links from a Brazilian government Java application. This is still affecting Fedora 36.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This patch was dropped from F37, so this should be fixed now. Hopefully.
(In reply to Michael Catanzaro from comment #14) > This patch was dropped from F37, so this should be fixed now. Hopefully. Which patch are you referring to?
https://src.fedoraproject.org/rpms/glib2/blob/f34/f/0002-gdesktopappinfo-Move-launched-applications-into-tran.patch
(In reply to Michael Catanzaro from comment #8) > It sounds like OpenJDK expects the application to launch without returning > to the main loop. Is that correct? If so, that would be an OpenJDK bug. It's > probably already broken in other distros if you try launching an app that > uses D-Bus activation, for example. It probably only worked in the past by > luck, because your web browser likely doesn't support D-Bus activation. > Alternatively, perhaps OpenJDK is misusing a GMainContext somewhere. This > can be very hard to debug. Ah, I see the underlying problem remains, and you can expect this problem to resurface eventually if not fixed. So I probably should not have closed this bug.
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.