Site navigation

URL::launchInDefaultBrowser not passing the Query String in Linux

Linux
#1

If I need to open a URL that contains a query string, everything after the first ampersand is ignored

URL w("https://www.mysite.com/?parameter1=value&parameter2=value");
w.launchInDefaultBrowser();

The browser opens with just https://www.mysite.com/?parameter1=value. I think this is due to the fact that, under Linux, launching the browser with a URL is done from bash, and the ampersand symbol in bash is a control symbol that causes the command to run in the background.

I think the problem is in the file \modules\juce_core\native\juce_linux_Files.cpp in the function bool Process::openDocument (const String& fileName, const String& parameters)
Quoting the command argument would fix the issue as the whole URL would be passed as string and the ampersand becomes part of the string.

Meanwhile, I’m doing this from my code, passing the URL string as a quoted string only for the Linux platform using compiler switches.

#2

No… I was wrong… if I do this:

auto s = "https://www.mysite.com/?param1=value&param2=value";
if (SystemStats::getOperatingSystemType() == SystemStats::OperatingSystemType::Linux) 
    s = s.quoted();

the browser opens with the URL:

https://www.mysite.com/?param1=value&param2=value%22%20||%20/etc/alternatives/x-www-browser%20https://www.mysite.com/?param1=value

So I’m stuck again with being unable to open a complete URL with the correct Query String under Linux.

Any help?

#3

I know this will end up as the umpteenth monologue on this forum, but just in case someone is curious… here’s what I came up with.

So, calling launchInDefaultBrowser() calls internally URL::toString() that splits the URL in the domain part + the URL-encoded query string, then passes this modified string to Process::openDocument() that tries to launch every possible browser from bash using the above string as the argument for the browser app.

The thing is that having an ampersand (&) symbol in a bash command splits the whole command in two or more parts, thus splitting the query string as well, resulting in the wrong URL being open in the browser. The solution would be quoting the entire URL, but while the first quote character is passed untouched (because it belongs to the domain part of the url), the last quote character is URL-encoded because it’s seen as part of the query string.

A trick that works is adding one extra ampersand at the end of the query string, then quote the entire URL, so the last parameter value isn’t compromised, but this would still throw some junk in the URL.

To have it working clean, the quoting must be done after the URL-encoding, so it should be done in the Process::openDocument() function; everything I can do in my code would not solve the issue without having to modify this Juce file.

#4

Be prepared to live with your juce fork for the years to come. Welcome to the club!

#5

LOL :slight_smile:

Actually, for this specific bug I have opened an issue on the GitHub repository and Ed Davies has applied the fix I was suggesting. Link

For other feature requests that I had and have not been accepted, I have created my own patch that I can apply as soon as the trunk is updated with a new stable release. I use TortoiseSVN and creating a patch is very easy, this way I don’t need my own fork.

#6

Honestly i prefer maintaining a fork and pull upstream into it while solving any merge conflict, rather than keep a set of patches around that will fail to apply sooner or later.

#7

What? A bug reported in github closed as fixed in less than 3 days? I couldn’t trust what my eyes see… :grinning_face_with_smiling_eyes:

2 Likes
#8

ROTFL :joy: