93141 - file:// needs to expand ~ to home directory in some OS

Status: RESOLVED FIXED

(Firefox :: Address Bar, enhancement, P3)

Description

[Jeremy M. Dolan]

split off from 82851.

file:///~/x.html should load x.html from my $HOME

file:///~kim/z.html should load z from kim's $HOME

very annoying to have to type in /home/jmd when I want to load a quick testcase
in my ~.

Comment 1

[benc]

Just for my amusement, are there aspects of "home" or "user" directories that
should be considered for other OSes? MacOS sort of lacks a home directory, what
about Windows or BeOS?

Comment 2

[Jeremy M. Dolan]

Windows kind of does... it has the users profile directory, which has the
documents and desktop directories in it. MacOS X probably does. BeOS is single
user as far as I know, so it wouldn't.

Windows, however, doesn't use "~" anywhere, so it's probably not a great idea to
support it. This would be UNIX only.

It occurs to me file: URLs logically don't support ~, since they start with an
unseen /, and /~ isn't valid. file:///foo is file "foo", not "/foo".. the / is
added by mozilla to do the fopen(). Is file:///foo correct, or was it supposed
to be file://host//foo to mean "/foo"...this more closely parallels Windows'
file://host/c:/.

Anyway, not being pedantic, it would still be very a very nice, friendly,
expected feature to support.

Comment 3

[benc]

I've spent some time looking at the RFC 1738 (which defines file URLs).

My feeling is that they meant for file URL's to be some method where a user
could have a path be encoded into a URL format. I do not think they meant for
users to be spending a lot of time with the URL's themselves, converting them by
hand.

I think what we should be doing is offfering users support for these funky file
conventions in the UI, and then doing the conversion to a file URL that is a
literal, absolute path. I guess another way of saying this is that if we provide
shell-style file naming, we need to do this in a user-level UI that supports
shell conventions, not inside the file URLs we eventually store and use.

Two obvious entry points would be the URL/location field in the browser window,
as well as the arguments parsed from launching mozilla from a command line
(currently we take a URL rather than a local file path, bug 50131).

As Jeremey said, "~" is clearly prohibited, so in the least it would need to be
encoded. 

Comment 4

[tenthumbs]

Related to bug 76968 maybe.

Comment 5

[Doug Turner (:dougt)]

'nix hackers please comment.

Comment 6

[timeless]

As a windows 2000 server user I do have %HOME% and you can call an api to get 
it, but I would _never_ expect ~ to take me there.  Nor would i want ~java to 
take me to the user java because on windows I'm quite likely to have a folder 
by that name (and given i run java applications for services i might have java 
as a user w/ restricted permissions).

MacOS9 and beyond definitely has a concept of user home.  BeOS has a concept of 
~, but normally it's not multiuser (that may change).  I wonder about OS/2 (and 
QNX which i didn't use long enough).

I think that puts me in agreement w/ benc, allow non file:// standard path 
formats and convert to absolute file:// paths.

Comment 7

[Mike Kaply [:mkaply]]

OS/2 is not multiuser and doesn't have the concept of a home.

This type of change should probably just go in nsLocalFileUnix

Comment 8

[Doug Turner (:dougt)]

future...

Comment 9

[R.K.Aa.]

*** Bug 123392 has been marked as a duplicate of this bug. ***

Comment 10

[Aleksey Nogin]

IMO, ~ should be also supported in file upload forms.

Comment 11

[benc]

Alexi: Please file a separate bug for that. You could probably send the "~"
character via escaping in the URL. 

Comment 12

[Aleksey Nogin]

Done, bug 142012 "RFE: support ~ in file uploads". Should it be markes as a
dependent on this one?

Comment 13

[benc]

Forms don't use file URLs (at least I hope they don't submit to a file...)

Comment 14

[Aleksey Nogin]

> Forms don't use file URLs (at least I hope they don't submit to a file...)
>
But forms may do file uploads - pls see bug 134143.

Comment 15

[benc]

Let's keep the bugs separate, b/c this question had to do will all uses of file:
URLs only. I have tapped the summary to be a bit clearer.

Comment 16

[Michael Hendy (Hendikins)]

*** Bug 241850 has been marked as a duplicate of this bug. ***

Comment 17

[Doug Turner (:dougt)]

mass reassigning to nobody.

Comment 19

[Benjamin Smedberg]

I think this should be WONTFIX: we don't want to provide attackers with easy access to the home directory location, and on most systems (including linux) the filesystem doesn't recognize ~ specially; it's expanded by the shell.

Comment 20

[lvm]

By the shell and by thousands of well-behaved programs, it is de facto a standard behavior - even mozilla's own Save As dialogs expand tilde properly. As for security concerns, they are trivial, I personally would consider a program which silently opens not the file it was told to open to be more insecure - if /file.html exists it will be opened instead of ~/file.html

Comment 21

[Mike Shaver (:shaver emeritus)]

Indeed, I made this work in LocalFileUnix some years(?) ago, and I don't think there's a security issue.  I disagree with it being WONTFIX, perhaps obviously, and I think the only missing platform at this point is OS X (which I'm not sure we supported when I did the LFU work, or I might have got it as well?).

Comment 24

[Boris Zbarsky [:bzbarsky]]

OSX uses nsLocalFileUnix now.  So it's just a matter of getting the ~ from the file:// URI to the local file code (and implementing ~ support on Windows, maybe; not sure whether nsLocalFileWin does the right thing with it).

Comment 25

[Tomer Cohen :tomer]

Is it possible to implement it on Android as well? Typing the whole path every time is way too long for typing.

Comment 26

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 28

[Vinny Diehl]

IMO this should be an address bar bug rather than nkfile, as one should be able to access the home directory simply by typing ~ into the address bar, rather than needing to specify file://~.

This behavior was implemented in Chromium with this commit, ~/foo gets expanded to e.g. file:///home/username/foo, and ~foo/bar is expanded to file:///home/foo/bar. Explicitly typing file://~/foo in Chrome does not expand to a valid filepath (it falls through to a search), but perhaps we can do better and support both ways? Either way, the path should be fully expanded by the time it reaches Necko.

I plan on looking into this soon, as I place one-off temporary test files in ~ quite often, and even for files nested deeper within the home directory it is convenient to go to ~ and then click around the directories from there.

Comment 29

[Marco Bonardo [:mak]]

If we're going to do it, it should probably be in URIFixup: https://searchfox.org/mozilla-central/rev/fb43eb3bdf5b51000bc7dfe3474cbe56ca2ab63c/docshell/base/URIFixup.sys.mjs#915,929,935-939
The fix may be as easy as changing the uriString.startsWith("/") with /^(~$|~?\/)/.test(uriString), plus adding some tests for ~ and ~/path and some negative non-matching tests.

Comment 30

[Vinny Diehl]

(In reply to Marco Bonardo [:mak] from comment #29)

The fix may be as easy as changing the uriString.startsWith("/") with /^(~$|~?\/)/.test(uriString), plus adding some tests for ~ and ~/path and some negative non-matching tests.

Wow, that was easy! /^[~/]/ appears to be sufficient for the regex. I've submitted a patch for review- you might suggest a better, more explicit way to test for the home dir (I'm currently using a regex that doesn't care what the user name is).

Home dirs for other users (e.g. ~foo/bar -> file:///home/foo/bar) are not yet supported- this might be something to do with nsIFile.initWithPath? I can't for the life of me find the implementation for this, if we decide that this addition is important, a nudge in the right direction would be appreciated.

Comment 31

[Vinny Diehl]

Attachment: Bug 93141 - Expand `~` to home directory when fixing up file URIs r?mak

Comment 32

[Marco Bonardo [:mak]]

(In reply to Vinny Diehl from comment #30)

Home dirs for other users (e.g. ~foo/bar -> file:///home/foo/bar) are not yet supported- this might be something to do with nsIFile.initWithPath? I can't for the life of me find the implementation for this, if we decide that this addition is important, a nudge in the right direction would be appreciated.

Does that work in Chromium?

Comment 33

[Marco Bonardo [:mak]]

Apparently nsLocalFileUnix only handles ~ or ~/abcd: https://searchfox.org/mozilla-central/rev/fb43eb3bdf5b51000bc7dfe3474cbe56ca2ab63c/xpcom/io/nsLocalFileUnix.cpp#310-311

My initial regex was indeed based on that, as I didn't know ~abcde was a valid path. To add support for that a bug should be filed under Core :: XPCOM component to modify nsLocalFileUnix.cpp.

Comment 34

[Vinny Diehl]

(In reply to Marco Bonardo [:mak] from comment #32)

Does that work in Chromium?

It does.

(In reply to Marco Bonardo [:mak] from comment #33)

My initial regex was indeed based on that, as I didn't know ~abcde was a valid path. To add support for that a bug should be filed under Core :: XPCOM component to modify nsLocalFileUnix.cpp.

Okay, sounds good. Filed as Bug 1847572.

Comment 35

[Marco Bonardo [:mak]]

In the Address Bar we'll take the approach in comment 28, I think that's reasonable and a parity bug.
It's unclear whether the original proposal is still worth it after 12 years of inactivity.

Though, before moving on, I'ld to get an opinion from network since this bug was moved from there. Should we move this back and file a new Address Bar bug?

Comment 36

[Kershaw Chang [:kershaw]]

(In reply to Marco Bonardo [:mak] (away 11-21 Aug) from comment #35)

In the Address Bar we'll take the approach in comment 28, I think that's reasonable and a parity bug.
It's unclear whether the original proposal is still worth it after 12 years of inactivity.

The approach in comment 28 looks reasonable to me. It looks like the URL spec doesn't require expanding ~ to home directory, so I think supporting this in Address Bar is right.

Though, before moving on, I'ld to get an opinion from network since this bug was moved from there. Should we move this back and file a new Address Bar bug?

Instead of moving this bug back, I think we can take the patch in this bug and file a new one if necessary. Thanks.

Comment 37

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/20cc4c9e2f08
Expand `~` to home directory when fixing up file URIs r=mak

Comment 38

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/20cc4c9e2f08