http://alexander.skwar.name/~askwar/stuff/text-with,comma http://alexander.skwar.name/~askwar/stuff/text-with Run: /usr/bin/firefox http://alexander.skwar.name/~askwar/stuff/text-with,comma Expected result: The URL http://alexander.skwar.name/~askwar/stuff/text-with,comma is loaded in the browser. Text displayed: If you see this text, the client loaded the complete URL, ie. WITH the comma (,) in the URL. Actual result: URL http://alexander.skwar.name/~askwar/stuff/text-with is loaded. Text displayed: If you see this text, the client shortened the URL before the , (comma). Assumed explanation: The , in the URL is causing problems. Although I did not test this, I assume that this bug will also effect seamonkey and any other application using mozilla-launcher. When I use the original firefox from http://mozilla.com/, I don't have this problem. I'm currently using mozilla-launcher-1.52-r1.
The bug only occurs, when there's already another firefox running (for the current user, I assume). If this starts up a new firefox session, it works just fine.
The original firefox doesn't do any magic with openURL and such. Instead, when "firefox http://alexander.skwar.name/~askwar/stuff/text-with,comma" is run, the folllowing gets eventually executed: ./firefox-bin http://alexander.skwar.name/~askwar/stuff/text-with,comma Maybe this could be adopted for mozilla-launcher? If not, then "special" characters, like the , (comma), should be urlencoded. At least for the URL given as a test case, http://alexander.skwar.name/~askwar/stuff/text-with%2Ccomma works as well.
Hmm... Where's the advantage of using mozilla-launcher over using /usr/lib/mozilla-firefox/firefox? I modified /usr/bin/firefox and did: +++ /home/alexander/tmp/firefox 2006-10-08 12:19:21.000000000 +0200 @@ -4,7 +4,12 @@ # but OOo brokenness makes it necessary to use a stub instead: # http://bugs.gentoo.org/show_bug.cgi?id=78890 +set -x + export MOZILLA_LAUNCHER=firefox export MOZILLA_LIBDIR=/usr/lib/mozilla-firefox export MOZ_PLUGIN_PATH=${MOZ_PLUGIN_PATH:-/usr/lib/nsbrowser/plugins} -exec /usr/libexec/mozilla-launcher "$@" +#exec ~/tmp/mozilla-launcher "$@" + +exec /usr/lib/mozilla-firefox/firefox "$@" + What will not work?
*** Bug 149215 has been marked as a duplicate of this bug. ***
Any idea, about when something might be done about this? I'd also like to know, what mozilla-launcher is good for - what would break, if it were dumped?
Ping?
Created attachment 101759 [details, diff] patch to mozilla-launcher to escape commas in urls
(In reply to comment #7) > Created an attachment (id=101759) [edit] > patch to mozilla-launcher to escape commas in urls > Having had a closer "look" at this, I dislike this patch. Reason: Up to now firefox eventually runs the openURL remote command. Users might know this and might make use of this. So a user might call "firefox http://gentoo.org/,new-tab" to have http://gentoo.org/ opened in a new tab. If this patch is applied, this won't work anymore.
URLs including ')' in them cause mozilla-launcher to fail as well.
(In reply to comment #8) > Users might know this and might make use of this. > So a user might call "firefox http://gentoo.org/,new-tab" to have > http://gentoo.org/ opened in a new tab. Talking about a command line interface, the cleaner approach would be something like "firefox --new-tab http://gentoo.org/" or something similar. Sure, that would break backward compatibility, but I believe it's worth it. It would be nice if we could make the launcher intelligent enough to handle this--
(In reply to comment #8) > Users might know this and might make use of this. > So a user might call "firefox http://gentoo.org/,new-tab" to have > http://gentoo.org/ opened in a new tab. Talking about a command line interface, the cleaner approach would be something like "firefox --new-tab http://gentoo.org/" or something similar. Sure, that would break backward compatibility, but I believe it's worth it. It would be nice if we could make the launcher intelligent enough to handle this--if the launcher is indeed needed, which I know nothing about yet.
Fixed in 1.56
Please reopen and revert the patch. This breaks all links in mails that have commas in them. Until a correct way to handle new-tab is found. My guess is that there are more users using firefox as a browser and tries to open links from a mail client then there are users using the ",new-tab" way. A better way would be to not filter commas but rather the valid command that can be sent to openURL.
(In reply to comment #13) > Please reopen and revert the patch. This breaks all links in mails that have > commas in them. It does? How so? I just verified, and when I run firefox http://alexander.skwar.name/~askwar/stuff/text-with,comma the URL "http://alexander.skwar.name/~askwar/stuff/text-with%2ccomma" is loaded. It shows the contents of the file "text-with,comma". Exactly like expected. When and where does the patch NOT work? Anyway - a better idea might be to NOT fiddle at all with the URL *AND* also *NOT* use openURL() at all anymore. As written in the comments of this bug, the plain "firefox" script from Mozilla.com works just fine. The mozilla-launcher covers just for some corner cases. > Until a correct way to handle new-tab is found. My guess is > that there are more users using firefox as a browser and tries to open links > from a mail client then there are users using the ",new-tab" way. I don't understand. As it is right now, the ",new-tab" stuff doesn't work anyway. Reason: ",new-tab" is converted to "%2cnew-tab". This is not a valid openURL() parameter and thus interpreted as part of the URL. > A better way would be to not filter commas Sort of. If openURL() is used, commas have to be filtered. Anyway. Please provide a testcase. Broken servers should not matter (only broken servers don't handle the translation %2c -> ,). My testcase is the following URL: http://alexander.skwar.name/~askwar/stuff/text-with,comma Try to load this URL and also: http://alexander.skwar.name/~askwar/stuff/text-with
Well as far as I can tell, according to rfc2616 and rfc2396 the comma is a reserved character that may not be escaped. But any way if the openURL() call is depreciated then why break legal url's to be compliant with openURL()? or see if openURL is in the call (possible?) and only then filter ",","(",")"
(In reply to comment #15) > Well as far as I can tell, according to rfc2616 and rfc2396 the comma is a > reserved character that may not be escaped. I'm still checking that. Care to point out, which sections of the FAQ mention, that reserved characters may not be escaped? I understand RfC 2396 so, that reserved characters (eg. "," or "?") are NOT to be escaped, if they serve a special function. Eg. the "?" serves as a delimiter in the Request URI as a delimiter between the "script name" and the query string (eg. in http://example.com/foo.htm?bar=yep, the bar=yep is the query string). In such a case, the "?" is not allowed to be escaped. In other cases it can (or sometimes must) be escaped. The same holds true for "," (although I don't know when or where the "," serves a special purpose IN REAL LIFE USAGE). > But any way if the openURL() call is depreciated then why break legal url's to > be compliant with openURL()? Simple - because otherwise, they don't work. If you pass "http://alexander.skwar.name/~askwar/stuff/text-with,comma" as a parameter to openURL(), Firefox (& SeaMonkey) will try to open the URL "http://alexander.skwar.name/~askwar/stuff/text-with". The ",comma" will be interpreted as a parameter on how to open. Basically, Firefox will then check if ",comma" is equal to ",new-tab" and as it's not and as openURL() doesn't know anything about ",comma", it'll silently ignore it. Result: http://alexander.skwar.name/~askwar/stuff/text-with is loaded. To overcome this, the , needs to be translated to %2c. > or see if openURL is in the call (possible?) and > only then filter ",","(",")" As long as openURL() is used, the "," (and also "(" and ")") always need to be escaped. Anyway - how about a testcase? Which URL breaks? All the URLs I tested worked. Granted, compared to the some billion URLs there are on the internet, I only tested a *VERY* minor fraction... :) Here's another working URL: http://www.spiegel.de/politik/ausland/0,1518,480652,00.html -> http://www.spiegel.de/politik/ausland/0%2c1518%2c480652%2c00.html
(comment #16) From the examples you've given it seems like the comma is used as a character in the url instead as a delimiter. In my url (like this: http://www.bovision.se/scripts/bovision/prenbesk.phtml?nnnnnn,nnnn&confirmed=1&OBJGUID=nnnnnnn&OBJTYPE=CMVILLA&nyabesk=1 (n=a digit, removed due to subscription info)) it is used as a delimiter. rfc2616: 3.2.3 URI Comparison rfd2396: 3.4. Query Component However as you said in comment #14: openURL() doesn't work now so why keep a fix for it that 1: doesn't work and 2: breaks other things?
Hm, I still don't quite understand. The test URL you provided seems to be using PHP (because of the .phtml). When I go to another test URL of mine, PHP (or Apache?) seems to translate the %2c to a , just fine. Compare http://digitalprojects.com/PHPInfo/index.php3?foo%2cbar=john.doe to http://digitalprojects.com/PHPInfo/index.php3?foo,bar=john.doe. Scroll all the way down to "PHP Variables". On both URLs, you'll find: _REQUEST["foo,bar"]. If I go to http://www.bovision.se/scripts/bovision/prenbesk.phtml?nnnnnn,nnnn&confirmed=1&OBJGUID=nnnnnnn&OBJTYPE=CMVILLA&nyabesk=1 (ie. with ,), I get an error message: Input string was not in a correct format. Could you provide a test case, please? Up to now, I'm not yet convinced, that the , -> %2c translation is breaking things in the real world (although I of course don't matter, as I'm not a dev...). Anyway, without a testcase, I suppose it'll be hard to convince the devs that something is broken and should be changed.
*** Bug 178224 has been marked as a duplicate of this bug. ***
