389469 - Protocol-handler applications that don't work when the browser escapes back-ticks, double-quotes, and spaces

Status: NEW

(Firefox :: File Handling, defect)

Description

[Robert Strong (they/them - no direct email)]

Attachment: handlers in html format from Windows

Tracks applications that no longer work (if any) after escaping back-ticks "`", double-quotes "\"", and spaces " " for url protocols handed off to the OS as implemented in Bug 389106.

Comment 1

[Karl Tomlinson (:karlt)]

Attachment: gconf url-handlers on Linux

On Linux,
For the 1.8* branches, the only url-handlers invoked from nsExternalHelperAppService should be those found from gconf under /desktop/gnome/url-handlers and those specified in Mozilla preferences.  (gnomevfs url-handlers are invoked from nsGnomeVFSProtocolHandler.)

This is a sample from 12 Linux users.  Several of them were using a Ubuntu derived system.  FC6 and Gentoo were also represented.  Don't know about many of the users though.

There are only 17 unique commands to test here:

/usr/libexec/evolution-webcal %s
/usr/libexec/gnome-cdda-handler %s
ekiga -c "%s"
evolution %s
gaim-remote uri "%s"
gaim-url-handler "%s"
gnome-help "%s"
gnomemeeting -c %s
mutt %s
nautilus "%s"
purple-url-handler "%s"
sound-juicer %s
sylpheed --compose %s
tomboy --open-note '%s'
totem "%s"
xchat --existing --url=%s
xchat-gnome --existing --url=%s

It seems that "%s" and %s and '%s' are treated equivalently by gnome_url_show: i.e. it becomes a single argument with no quotes - I think this is achieved through appropriate shell quoting, but I haven't studied to confirm there are no flaws.

Comment 2

[Karl Tomlinson (:karlt)]

Linux is more complicated on trunk, but I think that is a bug,
filed as bug #389632.

Comment 3

[lueckert]

I`m not sure if this is the same issue, but at least a similar one ;) I`m having trouble with a custom protocol link that works in Chrome, IE, and Edge, but not in Firefox (46.0.1) on Windows 8.1.
The application registered for the custom protocol expects a small JSON string as the first and only command line argument. Therefore, the custom protocol link always contains (encoded) quotes (") and may contain any other input from the user.

The handler is registered as:
"ReportDesigner.exe" "%1"

The JSON string for the argument might look like this:
{name:"User",authdata:[{value:"some_authentication_info"}]}

For use as a command line argument, quotes are escaped first (" -> ""):
reportdesigner://{name:""User"",authdata:[{value:""some_authentication_info""}]}

This string then is encoded as HTML-Attribute (default .NET Framework function) and used in an iframe:

<iframe src="reportdesigner://{name:&quot;&quot;User&quot;&quot;,authdata:[{value:&quot;&quot;some_authentication_info&quot;&quot;}]}"></iframe>

The log message in the Inspector window contains the right link:

    launching reportdesigner://{name:""User"",authdata:[{value:""some_authentication_info""}]}

But what Firefox passes to ReportDesigner.exe is:
reportdesigner://%7Buser:%22%22User%22%22,authdata:%5B%7Bvalue:%22%22some_authentication_info%22%22%7D%5D%7D

Where the other browsers pass:
reportdesigner://{name:"User",authdata:{value:"some_authentication_info"}}

Comment 4

[Masatoshi Kimura [:emk]]

It is a totally different problem. Please file a new bug.