Open agizis opened 4 years ago
The behaviour is the same if you use chromium-browser directly rather than through xdg-open, right?
Looking at xdg-open's documentation, I don't see it saying that it should launch the appropriate application and quit. Under some Desktop Environments, it will call an appropriate launcher that does this. But when running under LXDE, it falls through to "open_generic", which ends up just running the command within the shell script, so it won't return until the application it's calling exits.
If it's opening a local file, it will use pcmanfm, so you'll see different behaviour.
The rest might be one for John, although it's also likely to be just an upstream chromium issue.
Yes, you're right, it's exactly the same if I just call chromium-browser from the terminal. Nothing to do with xdg-open at all, sorry.
renamed ticket to not blame xdg-open.
It's a bit hard to check whether it's related to our patches to chromium or if that's just how that particular version of chromium behaves. I'd need to build a stock version to compare against, which is a bit involved.
Does this add any info to it? From an unprivileged (user pi) shell on the desktop. RPI 4B Buster with latest update/upgrade as of 12-Jan. The browser does open!! The gl_surface_presentation_helper.cc errors will repeat at intervals counting up as long as the browser is open.
pi@raspberrypi:/usr/lib/chromium-browser $ ./chromium-browser
[897:1124:0114/160721.272771:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[897:1124:0114/160721.273772:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[897:1124:0114/160721.274390:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[926:926:0114/160721.636098:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 1 times!
[1025:1:0114/160722.903096:ERROR:child_process_sandbox_support_impl_linux.cc(81)] FontService unique font name matching request did not receive a response.
[1025:1:0114/160722.908336:ERROR:child_process_sandbox_support_impl_linux.cc(81)] FontService unique font name matching request did not receive a response.
[897:1164:0114/160730.262201:ERROR:shared_change_processor.cc(196)] Passwords datatype error was encountered: Change processor disconnected.
I know this is really sleazy but by running a subshell with its stdout and stderr redirected, I was able to accomplish the desired result (opening a browser to get an OAuth PIN for input to a ReadLine in the terminal window.) C#/.NET Core
ProcessStartInfo pi = new ProcessStartInfo("bash", $"xdg-open {url}");
pi.RedirectStandardError = true; // Hide the **** from the parent terminal
pi.RedirectStandardOutput = true;
Process.Start(pi);
Is this the right place for my bug report? Eben Upton told me to create it here, even though it’s “not really the appropriate repo, but it will do”
Describe the bug Bad things happen using /usr/bin/xdg-open to open urls in Chromium. Sometimes it works fine, sometimes Chromium freezes up, sometimes the whole desktop environment freezes up tens of seconds. Once I had to pull the plug because after minutes it didn’t come back.
To reproduce Open a terminal and run this command several times: /usr/bin/xdg-open "https://support.speedify.com/"
Expected behaviour If the browser’s not running, it should start on the URL, if it’s not it should quickly open another tab to that URL.
Actual behaviour Most times it works, but sometimes, it takes a very long time and the browser or even the whole desktop freeze up while it’s waiting.
Here I ran it a couple times. See the large “ERROR:browser_process_sub_thread.cc(217)] Waited 678 ms for network service” type messages. Ive seen them go above 3000 and that’s when things get really hung up (for much longer than the 3 seconds you’d think from the message)
And sometimes when it has to launch chromium, it does, but the command never returns at all. I added some <> inline:
System Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:
Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW 4B
Which OS and version (
cat /etc/rpi-issue
)? Raspberry Pi reference 2019-09-26 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 80d486687ea77d31fc3fc13cf3a2f8b464e129be, stage5Which firmware version (
vcgencmd version
)? Sep 24 2019 17:34:30 Copyright (c) 2012 Broadcom version cd3add54955f8fa065b414d8fc07c525e7ddffc8 (clean) (release) (start)Which kernel version (
uname -a
)? Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/LinuxLogs If applicable, add the relevant output from
dmesg
or similar.Additional context Add any other relevant context for the problem.