1891484 - (`file` schema-denoted) URIs entered into address bar do not interpret environment variables correctly.

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[Mr. Beedell, Roke Julian Lockhart]

I want to visit file://localhost/home/RokeJulianLockhart via the address bar using the $HOME environment variable. However, I am unable to if I utilize $HOME (rather than inputting that path directly) despite $HOME being set:

"$Env:HOME"

produces /home/RokeJulianLockhart.

I've tried all the potentially valid combinations:

1. "file://$HOME/"
   

   Because $HOME's value of /home/RokeJulianLockhart begins with / (rather than merely home/) omitting one of the slashes should make sense so that there are not 4 slashes. It does not work:

   1. When file://$HOME/RokeJulianLockhart is entered:
   2. It becomes file:///RokeJulianLockhart.

2. "file:///$HOME/"
   

   Because the 1st option didn't work, one would expect that actually, multiple slashes are removed during interpretation. However, they are not:

   1. When file:///$HOME/RokeJulianLockhart is entered:
   2. It remains file:///$HOME/RokeJulianLockhart.

3. "file://localhost/$HOME/"
   

   Even explicitly including the (local loopback) hostname doesn't work:

   1. When file://localhost/$HOME/ is entered:
   2. It remains file:///$HOME/.

   However, this would be undesirable anyway, considering that localhost is mere convention, rather than something worth explicitly relying upon instead of absence of hostname

This doesn't make any sense to me.

Comment 1

[Mr. Beedell, Roke Julian Lockhart]

https://bugzilla.mozilla.org/show_bug.cgi?id=1891484#c0

https://gitlab.com/rokejulianlockhart/rokejulianlockhart/-/commit/607fb20b76e3decdfb8e50f1091a33fabb681bf1#c6b1a86c86c2b7aa11c9f68f566d1f25461c9924_266_265 is an example of when this is useful. I was using Firefox to attempt to test it.

Comment 2

[Marco Bonardo [:mak]]

This would likely be implemented in xpcom/io/nsLocalFileUnix.cpp, so moving to Core / XPCOM (other similar bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=1847572 have been handled there).

Comment 3

[Mr. Beedell, Roke Julian Lockhart]

Thanks, [e-mail]. https://bugzilla.mozilla.org/show_bug.cgi?id=1847572#c0 is similar. (However, I'm surprised that it was implemented - it's very much a bash-specific feature.)

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:nika, could you have a look please?

For more information, please visit BugBot documentation.

Comment 5

[Nika Layzell [:nika] (ni? for response)]

I don't think this makes sense to implement support for. In general, file URIs are intended to use absolute paths, and don't pull values from shell environments. I think I'm inclined to mark this WONTFIX, as the URL bar isn't a BASH shell.

Comment 6

[Mr. Beedell, Roke Julian Lockhart]

https://bugzilla.mozilla.org/show_bug.cgi?id=1891484#c5

[e-mail], environment variables are not whatsoever specific to bash. However, I agree that it shouldn't be treated as such. Yet, in that case, why was https://bugzilla.mozilla.org/show_bug.cgi?id=1847572#c0 implemented - a literal bash-specific feature?

Comment 7

[Nika Layzell [:nika] (ni? for response)]

IIRC the reason support for typing ~/path/to/file into the URL bar was added was due to equivalent support in other browsers like Chrome. IIRC you can't include ~ in a file:/// URI either way, it effectively only impacts typing a bare path in the URL bar. I believe this reasoning isn't also present for the shell $ENV syntax being allowed within file URIs.

Comment 8

[Mr. Beedell, Roke Julian Lockhart]

https://bugzilla.mozilla.org/show_bug.cgi?id=1891484#c7

[e-mail], isn't "the shell $ENV syntax what I'm requesting - the ability to use environment variables ($HOME, for instance) in file:// URIs?

Comment 9

[Nika Layzell [:nika] (ni? for response)]

Yes, I am aware you are requesting the ability to use shell $ENV syntax within file URIs. My comment was explaining how the situation in bug 1847572 is not equivalent to that feature request, in response to your question in comment 6.