Does any other browser do what you expect?

Also reproducible on Linux. 

Hello!

Safari handles this task correctly as I've expected. FireFox is doing this in same way as Chrome.

Deleted: Firefox.png 96.3 KB

	Firefox.png 96.3 KB View Download

Deleted: Safari.png 49.9 KB

	Safari.png 49.9 KB View Download

Thank you for providing more feedback. Adding requester "karandeepb@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hi, guys!

May I ask about status?

That's really mandatory for any Atom IDE users who want to develop in Go language.

This feature broke all black magic for GOPATH.

+people who might have an opinion on this.

Would there be a command line flag to choose between these, or would we default to always showing the symlink? I can't think of a particular security concern with the latter, but I haven't thought it thoroughly either.

Sounds like a URL canonicalization issue.  brettw@ or pkasting@ may have thoughts on whether it can be fixed.

I don't know enough about canonicalization to know where this would be offhand, and lack a Linux box to set up true symlinks to test.

URl parsing and canonicalization doesn't touch disk. If any code is doing this, it's in the net component.

mmenke@: Do you know any network folks who might be familiar with this (per comment 12)?

net/ doesn't actually support symlinked paths.  You can verify this by going to file:///Users/pavel/myapp_symlinked_path/index.txt (Modified as appropriate).  I'd guess that this behavior is handled by the code that handles processing/validating of URLs passed to Chrome on the command line.  This code does not live in net/.

Presumably if we wanted to remove that logic, we'd want to add support in net/ for using symlinked paths, first.  Note that this raises potential security questions for any code that does security checks on file URLs (We do this on Android, not sure if we do it elsewhere).

I looked into this.

This doesn't happen if you type in the URL bar, it only happens from the command-line.

This is happening in the code that interprets the command line. The command-line handling is special because you can type "google.com" to go to Google (despite this not being a real URL), or relative file names.

As part of this, url_fixer.cc's ValidPathForFile calls base::MakeAbsoluteFilePath to get the absolute path to the input. This function ends up calling (on Posix) realpath(). This resulting path is then used to construct the final file URL.

realpath() is doing a bunch of work for us in terms of resolving ".." stuff and probably handles a bunch of weird edge cases that I can't even think of.

If you want to work around this, you can always supply a real file URL on the command line, or type the URL you want in the URL bar.

Is it even possible to avoid having ValidPathForFile() call MakeAbsoluteFilePath()?  In other words, if we left relative paths as relative, could we successfully open them?

I'm wondering if the "resolving .. stuff" etc. is fixup that we truly need to do.

file URLs don't support relative paths.  If you prefixed relative paths with the current directory, though, and then just wrapped them in a file GURL, that would work.

Brett, do you think converting MakeAbsoluteFilePath() to do the dumber implementation in comment 17 would break things?

I can't think of what comment 17 would break offhand. It would need to be implemented carefully. The obvious way is to do FilePathToFileURL(GetCurrentDirectory() + "/").ResolveRelative(input)
but if there are special characters in the input like # or ? they won't be escaped properly for file URLs.

Removing Internals>Network based on c#14/15; it sounds like the locus of this problem isn't in net/