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

NEW
Unassigned

Status

()

11 years ago
2 years ago

People

(Reporter: rstrong, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Created attachment 273667 [details]
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.

Updated

11 years ago
Summary: Applications that don't work when escaping back-ticks, double-quotes, and spaces → Protocol-handler applications that don't work when the browser escapes back-ticks, double-quotes, and spaces
Created attachment 273916 [details]
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.
Linux is more complicated on trunk, but I think that is a bug,
filed as bug #389632.

Updated

2 years ago
Component: File Handling → File Handling
Product: Core → Firefox

Comment 3

2 years ago
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"}}
It is a totally different problem. Please file a new bug.
You need to log in before you can comment on or make changes to this bug.