Lib.getURL() doesn't work in Ubuntu

[larsiusprime]

Reproduction case:

var request  = new URLRequest("https://www.google.com");
Lib.getURL(request, "_blank");

What I expected:

• For google.com to open in a new browser window (this is the behavior on windows)

What happened instead:

• No window opened, and this was printed to the console I launched the application from:

  xdg-open: unexpected argument '&'
  Try 'xdg-open --help' for more information.

Using Ubuntu 18.04.2 LTS

[jcward]

Same here. This is launched from:

https://github.com/openfl/lime/blob/develop/src/lime/system/System.hx#L301

[larsiusprime]

Figured it was something like that. What is the "&" trying to do there?

[larsiusprime]

Just tried both these directly on the command line: xdg-open https://www.google.com xdg-open https://www.google.com &

Both of them work, the latter however also returns some stuff: [1] 27835

So that's presumably the point of the "&" parameter ... but I guess it's getting mangled on the way over?

[jcward]

Removing the "&" makes it work.

When typed at the end of a command, that will launch a command in the background. I'm not sure if it's necessary here... That 27835 is the process ID that was put in the background. But xdg-open returns immediately anyway, which is why I wonder whether it's necessary.

[larsiusprime]

I'm all for getting rid of it if that's the solution, but in the name of Chesteron's Fence I'd like to find out why it was stuck there in the first place, if that's something we can figure out. Gonna check the blame history to see if there's a useful commit message...

[jcward]

I looked back in git -- it's 3 years old, and came with the first implementation of that functionality:

https://github.com/openfl/lime/commit/54a8f32f60a3a6c00d985be17eb98c8ffd101078

Although it's possible that, if it used to work, Haxe's Sys.command escaping has changed... It's actually passing "&" as an argument. e.g. as if you ran:

/usr/bin/xdg-open "https://www.google.com" "&"

[larsiusprime]

Cool. Well I'll make a quick bodge locally to fix my build, and let's ping @jgranick to get an answer on whether we can just remove this "&" parameter.

[larsiusprime]

@jcward you're right on the money. That's the issue

xdg-open "https://www.google.com" "&"
xdg-open: unexpected argument '&'
Try 'xdg-open --help' for more information.
[1]+  Done                    xdg-open https://www.google.com

xdg-open https://www.google.com &
[1] 27980

[larsiusprime]

(I'm using Haxe 3.4.7 for the record)

[jcward]

Ah -- I seem to be using Haxe 4 rc5, so perhaps chances are, Sys.command's hasn't changed.

[larsiusprime]

Well, this is probably a little-used enough feature that we're the first to notice it? I haven't seen any other relevant bug reports about this. How often do you launch URL's from a native app, in linux?

The problem is definitely caused by quoting the "&" sign. So either this has been broken on Linux from the start, or an even earlier version of Haxe had unescaped parameters.

Relevant question for us is -- how do we fix this behavior? It's easy enough to drop the &, but I suspect this auto quoting thing might be causing trouble elsewhere so it might be smart to figure out how to get around it now.

[jcward]

Well, & is technically not an argument. Yeah, the docs for Sys.command specifically says that arguments will be quoted, which is correct / desired behavior.

I know I've used an & before... ah yes, hxScout had a splash screen that launched the main app:

var code = Sys.command(Sys.getCwd()+"hxScoutMain &");

But if you use it in the cmd string, you have to supply (and escape) your own arguments.

One could argue that if '&' is the final "argument", that it should not be quoted, to give the desired effect on OSX and Linux (launch in the background). But that's assuming you always want that behavior. It'd be better if "launch in background" was an optional parameter to Sys.command (on OS's that support it.)

Oh, look, the above doc mentions background processes:

Read the sys.io.Process api for a more complete way to start background processes.

[larsiusprime]

So the issue is that we need to swap out the linux implementation with a call to Process instead of Sys.command, the latter being for more simple use cases?

[jcward]

Well... if xdg-open is expected to be a long-running process, then yes. But it appears that xdg-open returns immediately. In other words, there could be no reason to background it, which would mean, just remove the "&".

Ah, this answer suggests that it does wait of the program to finish -- ah, but the comments are controversial... https://unix.stackexchange.com/a/74631/103904

So perhaps it's chrome that's taking the URL and letting xdg-open exit?

Hmm, maybe safest to use sys.io.Process, so your game doesn't lock up.

[joshtynjala]

Closing old issue, which appears to be fixed.

openfl/lime@6900d189718de3b25605fb73e4a402d7e7ac454f