107153 - file:/// urls in history show up under (no host) instead of "My Computer" or something else

Status: RESOLVED INVALID

(Core Graveyard :: History: Global, defect)

Description

[(not reading, please use [e-mail] instead)]

file:/// urls in history show up under (no host) instead of "My Computer" or 
something else.

on IE, they show up under "My Computer".

I'm not sure what we'd do for unix ("localhost"?) or mac.

Comment 1

[alge]

Isn't "My Computer" a bit.. urgh.. MS-ish? "Local file" would be better, imho.
Out of dozens of computers I use mozilla on, only one is actually _mine_. (=

Comment 2

[Alec Flett]

we could have a per-platform string, but it would incur the overhead of a 2nd
platform-specific string bundle, etc.

Maybe we just need something better than "(no host)" like "Local Files"

I'm personlly somewhat against "My Computer" as well...

Comment 3

[timeless]

I'm against both My Computer and Local Files, hrm, but maybe that's because of a
bug. i suppose i should check, ok it's a bug. cc'ing benc in case it's a known bug.

file://///foo/bar is not local. nor is file://///192.168.20.10/bar/baz

if that's fixed then local files would probably be ok w/ me.  however i know
that QNX has qnet (eg file:///net/audrey) which could be a remote location, and
unix has nfs/smb mounts so ...

Comment 4

[Alec Flett]

good lord, we're not going to try and be smart about unc paths, nfs mounts, and
such. if a file is accessable via a file:// url then it's considered local, even
if it is acutally mounted from another machine.

Comment 5

[benc]

Right now, we don't even parse the hostname for file URL's when necko accesses
them (bug 70871), so history is doing something smarter than the rest of
mozilla. You can try adding a bogus hostname in your file URLs (between slash 2
and 3), and see if history indexes them.

necko ignores them, so file://canttouchthis.com/etc/hosts == file:///etc/hosts,
for right now.

For standards-mozilla-ish UI, I think the description is technically correct,
but maybe "local file" would be a better tag. I don't think there are any URL's
that appear in history that can have a void hostname except file URL's, so this
would probably be okay.

For Netscape/consumer-level UI, I think the underlying confusion would be
related to the fact we sort history exclussively by time > hostname. Somewhere,
I would expect we need to think about sorting by scheme (ftp vs. http)...

Comment 6

[Alec Flett]

history just uses necko to parse the URL and tries to get the Hostname attribute
from nsIURL - if this fails, then its listed as "(no host)"
it doesn't actually distinguish file: urls 
(but I wasn't lying above - I mean that we should focus on parsing the URL and
not try to ask the system where the file that corresponds with that file really
exists)

Comment 7

[benc]

Well, it's unlikely to show up, but you might want to play with some file URLs
that do have a valid hostname and see how it looks in history.

For example:

file://www.netscape.com/etc/hosts
file:///etc/hosts

In file URL's, the hostname is a validator, if the machine running the browser
is not the hostname (if you are not "www.netscape.com"), then the file URL is
invalid.  In retrospect, I've come to think this was a bad idea.

Comment 8

[timeless]

re comment #5 p3, will these ever be in history: [about:, javascript:, data:, 
resource:, chrome:]?

about: generally resolves to chrome:; chrome: resolves to resource: or 
somenetprocol; resource: resolves to file:.
data: and javascript: can have remote origins, be manual, and javascript: can 
be manually attached to a remote origin.

beyond that, as a developer i don't mind localhost, as a windows or mac user 
i'd probably have no idea what it meant.  For mac users, there's a concept of 
'this macintosh' (About this Macintosh).

Comment 9

[Blake Ross]

To all of us, "My Computer" obviously sounds ridiculous.  But I think we should
consider using it for compatibility with IE, and so that users know what we're
talking about.  Do users really grasp the concept of "local" versus "on the
internet" files if we were to go with Local Files?

Comment 10

[Peter Trudelle]

I agree with Blake, it isn't about what sounds good to us, but rather being
consistent with what users are presented in the OS, and on Windows, that is
clearly "My Computer". I don't know of a Mac equivalent, but I'm pretty sure it
is not "this Macintosh".  Users can name their Macs, so perhaps we'd use that? 
Localhost is okay on Linux, if the machine has no domain name.   I'm not even
sure what "local" is in general anyway, since it is always used relative to
"remote", and could just as easily mean files on the LAN or intranet.  We use it
for folders in mail, but I doubt many people really know what is meant.

Comment 11

[timeless]

Ok, i'm told the mac's name is controlled: <blockquote 
src="irc://irc.undernet.org/#macintosh">
in MacOS 9, you want the Filesharing control panel.
in the Start/Stop tab, you can fill in machine name in the top section of the 
dialog box (helpfully labeled Network Identity)
</blockquote>

However, if you're going to use that then i'll complain because windows has 2 
computer names, and one of them really sucks.  The one that sucks (w2k) is my 
computer properties>network identification.  It's used by DHCP which means that 
if you're some poor sap (like me) who has @home (or its successor) then your id 
is some ugly ccXXXXXXX thing.

The other is of course the thing you to which you can rename 'my computer'.

Hrm, i think i can actually rename The Internet, My Computer and Network 
Neighborhood to the same string (yes we know i'm pathological).

Supposing that i named my computer www.yahoo.com, would all of my 'local' urls 
appear in the same place as real pages from the real www.yahoo.com? and is that 
a bug?

Actually for resource: we should probably use 'Application' (perhaps 
&AppShortName;) or something like that.

Comment 12

[[e-mail]]

For Mozilla, one vote for "local filesystem"

It is technically accurate, most people understand that WAN connected file space
is transparent to most file managers.

Netscape should make a design decision and overlay that in the commercial build.

Comment 13

[Matthew T (active 1999-2002)]

I've never used the File Sharing control panel (though I have admired its
icons), and I wouldn't have a clue what my computer is called. (Oh, look. It's
`Matthew Thomas's Computer'.)

Remote URIs aren't grouped all under `Remote Files', so I wouldn't expect local
URIs to be grouped all under `Local Files' either. I'd expect them to be grouped
by the name of the disk, e.g. `Macintosh HD' (And possibly the icon for that
folder should be the same as the icon for the disk, though some part of me which
isn't quite awake at the moment is expressing misgivings about that detail.)

Comment 14

[Alex Bishop]

> Remote URIs aren't grouped all under `Remote Files', so I wouldn't expect local
> URIs to be grouped all under `Local Files' either.

At the moment, URIs are grouped by server. Think of your computer as another server.

> I'd expect them to be grouped by the name of the disk, e.g. `Macintosh HD'

I think that could be a little confusing. Most users probably have a pretty firm
idea that they have their own files are distinct from those on the Internet.
Having their disk drives mixed in with other Internet servers may disorientate
them. Plus, it wouldn't work well on Windows, where Microsoft likes to pretend
that 'Desktop' is at the top of the computer's hierarchy (when it's actually
located at C:\Documents and Settings\Alex\Desktop in my case).

Comment 15

[benc]

Cookies is having a similar quandary in bug 161636.