161033 - bookmark keywords should escape \ instead of converting it to /

Status: RESOLVED WORKSFORME

(SeaMonkey :: Location Bar, defect)

Description

[timeless]

steps
bookmarks:
create a bookmark
location: http://lxr.mozilla.org/seamonkey/search?string=%s
keyword: lss

navigator
ctrl-shift-l
lss \.ico <enter>

expect
http://lxr.mozilla.org/seamonkey/search?string=%5C.ico
actual results:
http://lxr.mozilla.org/seamonkey/search?string=/.ico

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is windows-only; URI fixup is the culprit.

Comment 2

[timeless]

Attachment: only convert if the file exists

create a bookmark
location: http://lxr.mozilla.org/seamonkey/find?string=%s
keyword: lsf

testcases:	current results:	new results:
c:\config.sys	file:///c:/config.sys	file:///c:/config.sys
c:\nosuchfile	"The file /c:/nosuchfile could not be found."	"c is not a
registered protocol."
lsf \.xpm	http://lxr.mozilla.org/seamonkey/find?string=/.xpm     
http://lxr.mozilla.org/seamonkey/find?string=%5C.xpm

For reference, explorer.exe gives:
<title>Address Bar</title>
<p>Cannot find the file or item 'c:\nosuchfile'. Make sure the path and file
name are correct. Type 'go &lt;SearchText&gt;' to use AutoSearch.</p>
<center><input type=submit value="Ok">

Currently the middle case's error is confusing for windows users, the new error
will be slightly worse but it needs to be fixed anyway and it's an edge case
that can be addressed at another time.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Could this possibly allow remote people to test for the existence of local files?

Comment 4

[timeless]

i'd hope not, afaik urifixup is only supposed to happen when you enter an
address in the location bar.

Comment 5

[Adam Lock]

Comment on attachment 117093 [details] [diff] [review]
only convert if the file exists

I don't think this patch is the right way to fix the issue. If the URL is
file-like in nature, e.g. c:/foo.txt and the bit before the colon corresponds
to no known protocol then the method should fix it up as if it were a file,
regardless of whether the file exists or not.

e.g.

nsCOMPtr<nsIProtocolHandler> handler;
ioService->GetProtocolHandler(aIn.get(),   getter_AddRefs(handler));
if (!handler)
{
  // file fixup regardless
}

Even if the file does not exist, the fixup should be the same. Perhaps
permissions don't allow the user to see the file at that moment, or perhaps the
file sometimes doesn't exist and sometimes does (e.g. log file), so it
shouldn't be treated differently in that regard.

I don't know of any exploits that might use the different fixup to 'sniff' for
files, but if there is a way to invoke fixup somehow e.g. via window.open or
some other means I wouldn't like to make an exploit possible either.

Comment 6

[Jesse Ruderman]

*** This bug has been marked as a duplicate of 123006 ***

Comment 7

[Jesse Ruderman]

e-mail from timeless:

-----
it's not a dupe.

Here's the flow:

a. user enters url
b. urifixup converts \ to /
c. bookmark keywords do stuff

your bug [bug 123006] talks about c. by the time my url reaches point c, it's
already been munged at point b. 
-----

Comment 8

[Philip Chee]

Places bookmarks appears to be WORKSFORME in that it doesn't convert \ to / It doesn't escape \ either but that seems to work.