New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 45051 link

Starred by 18 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jun 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

can't type filenames with backslash (\) in them in the omnibox

Project Member Reported by tony@chromium.org, May 26 2010

Issue description

What steps will reproduce the problem?
1. Create a file with a backslash in the filename, e.g., touch "test\\file.txt"
2. Try to navigate to the file by typing file:///path/to/test\file.txt
3. The navigation fails because the \ is converted to /.

It does work if I escape the \ with %5C and the omnibox cleans up the display and shows it as a \.  If 
I then press 'go', it says the file is not found.  If I press reload, it works as expected.

I'm not sure if this is a bug in GURL or a bug in FixUpURL.

 
Labels: -Area-Internals Area-UI Feature-Omnibox Mstone-X
Status: Assigned
Hey Peter, do you have any thoughts about whether this is the right thing to do?
The difference between Go and Reload is that Go is like hitting enter in the omnibox, 
while reload ignores the omnibox text entirely.

As for how we should parse and escape \, that's a brettw question.  I know on Windows 
we normally interpret both the same way, and I think that's to match IE and/or make UNC 
paths work.  Maybe we shouldn't do that on Linux.  Or maybe we should, but we shouldn't 
unescape %5C.  Or something.  I don't know.

Comment 3 by brettw@chromium.org, May 27 2010

Status: WontFix
It's also impossible to type filenames with other characters like #, ?, and % since 
those also have special meaning in URLs.

We always treat backslashes the same as forward slashes. This happens even in URLs on 
web pages (other browsers do this) but is especially important for the omnibox, since 
most users have no idea which slash is which (how many times have you heard somebody 
on the radio tell you to go to "foo dot com backslash bar"?).

So I think we have the correct behavior. I could imagine an argument that Linux users 
are super smart and can always do the right thing (which I think is incorrect), but 
considering the same problem with a handful of other characters, it seems like a 
losing argument. You can always type the escaped version, navigate, or use the "file 
open" box.
The only question I have is whether we should really unescape "\" in the path portion 
of a URL.  If we leave this escaped, then at least if someone types the escaped 
version, it will work more than once.  WDYT?

Comment 5 by tony@chromium.org, May 28 2010

I think leaving '\' as %5C would be good.  You could imagine someone browsing to the URL via the local directory 
browser and wanting to copy/paste the URL somewhere (in which case the %5C would work in other places).

Also, should we special case file:/// urls on Linux and Mac?  Unix shells won't allow backslash, so I wouldn't 
expect file:/// urls to autoconvert these either.

Comment 6 by tony@chromium.org, May 28 2010

FWIW, on Firefox on Linux, I can type file:///foo/bar/test\file.txt and it successfully loads the file.
Status: Assigned
I'm reopening at least for the escaping question.  I have some sympathy for Tony's 
comment that we should perhaps behave differently on different OSes (although we also 
need to check what these browsers do when you have a link like this, as opposed to 
typing it in the address bar).
 Issue 25916  has been merged into this issue.
Status: Untriaged
Project Member

Comment 10 by bugdroid1@chromium.org, Dec 3 2010

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=68200

------------------------------------------------------------------------
r68200 | brettw@chromium.org | Fri Dec 03 11:49:08 PST 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/escape.cc?r1=68200&r2=68199&pathrev=68200

Don't unescape backslashes in URLs, since these will be converted to slashes
by googleurl, changing the meaning of the URL.

BUG= 45051 
TEST=none
Review URL: http://codereview.chromium.org/5603005
------------------------------------------------------------------------
Status: Assigned
Brett's fix in r68200 implements the first half of comment 5.

Brett basically vetoed the idea of not doing this fixup in googleurl for non-Windows platforms.  Given that, there isn't much I can do in the omnibox, since everything relies on googleurl's fixup code (among other things).

The only other option is to make this behavior switchable in googleurl, and normally do the fixup, but turn it off for this particular case (fixing up the omnibox input on non-Windows platforms).  I'll assign this to Brett to decide if that's feasible.  I think it'd be nice, personally.
It's one thing to change backslashes to forward slashes when a user types them in, but this bug also shows up when following hypertext links. I just came across an example of this in the OpenCV documentation:
 1) Navigate to http://opencv.willowgarage.com/documentation/cpp/index.html
 2) Click on the link "Namespace cv and Function Naming" under "Introduction"
 3) ~Page is not found~

Meanwhile, the page does exist:
http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBMQFjAA&url=http%3A%2F%2Fopencv.willowgarage.com%2Fdocumentation%2Fcpp%2Fnamespace_%255Ctexttt%257Bcv%257D_and_function_naming.html

Comment 13 Deleted

Jonathan: The autocomplete bar breaks because we do this for all URLs, mostly for cases like your example: in general nobody knows the difference between forward slash and backslash. Backslash in the query, as in your example, is not listed as valid by RFC 3986. The page is broken, it just happens to work in Firefox.

As such, changing backslash handling is almost certain to break stuff more than it "fixes."

Comment 16 by tony@chromium.org, Oct 13 2011

Cc: brettw@chromium.org
 Issue 100052  has been merged into this issue.
Status: Available
It's not clear how to proceed here.

 Bug 100052  can only be fixed if we at least escape backslashes in the path component of HTTP-like URLs.  It sounds from Brett's comment 14 like he believes that even this would break a lot of real-world stuff.

Another possibility is to restrict to only doing that escaping for manually-typed URLs, and nowhere else, but I don't know if this is better or worse.

Comment 18 by jyass...@gmail.com, Oct 13 2011

From  issue 100052 : On Mac, Firefox and Safari do not rewrite '\' to '/'.

Comment 19 Deleted

Comment 20 by mgc...@gmail.com, Nov 22 2011

Changing \ to / is breaking hyperlinks in FogBugz to our local OneNote files. These Hyperlinks are UNC based and have to retain their backslash. 

Can't believe this is not an option and we're pushed into using IE or FF to work.
mgc250: What you're describing is a separate issue (hyperlinks versus omnibox input). Chrome's UNC handling should match IE very closely in this respect.

Probably what you're seeing is the restriction that file: links won't work on http: pages. See http://stackoverflow.com/questions/2087894/can-google-chrome-open-local-links
Project Member

Comment 22 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-UI -Feature-Omnibox Cr-UI-Browser-Omnibox Cr-UI
Another case here to note: converting \ (backslash) to / (forward slash) in URLs opens up some sites to relative path based attacks. For example, "/legal/path/to/a/file\..\..\..\..\..\..\illegal/path/to/other/file.txt". Regex or prefix path based scanners will allow this through because the \ is treated like a regular character, but then chrome autoconverts the backslashes to forward slashes which is a totally different path than the one which was verified as valid/safe.
Project Member

Comment 24 by sheriffbot@chromium.org, Jun 26 2016

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been available for more than 365 days, and should be re-evaluated. Hotlist-Recharge-Cold label is added for tracking. Please re-triage this issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
pkasting: can you reexamine this bug and decide if it's worth leaving open?  It's been years and your last comment included "It's not clear how to proceed here."
Status: WontFix (was: Untriaged)
I don't believe we can proceed further here.
Cc: jkwang@chromium.org
 Issue 782833  has been merged into this issue.

Sign in to add a comment