Location Bar Proposal

120 views
Skip to first unread message

Gervase Markham

unread,
Feb 15, 2007, 1:19:34 PM2/15/07
to d...@design-noir.de
I've been following bug 366797, and discussions in mozilla.dev.security,
with great interest, and I've been thinking about this for some time
now. Here's my (slightly long) attempt at a unified and consistent
proposal for changing the way the location bar works for Firefox 3.

In the original design of the web, the URL was supposed to be an
implementation detail. That hasn't turned out to be the case, for better
or for worse. Still, the URL bar itself has changed very little since
Netscape 1. I believe there's scope for changing the way it works to
improve the user experience.

The blog version of this proposal takes advantage of HTML formatting and
has some crude mockups, so might be easier to read:
http://weblogs.mozillazine.org/gerv/archives/2007/02/location_bar_proposal.html

However, please put all comments in this newsgroup.

Goals:

- Don't break stuff people use
- Make the hostname stand out more to reduce spoofing
- Reduce the risk of spoofing in other ways
- Make the contents of the URL bar more understandable
- Make common operations easier

Optional Goal:

- Find a way of presenting information from EV certificates

Suggested Changes:

1) Hide the scheme

The scheme (e.g. "http://", "ftp://") should be hidden permanently for
HTTP, HTTPS, FTP and file URLs. The differences between HTTP and FTP
have long since ceased to matter to the average web user. The difference
between HTTP and HTTPS is, of course, important, but we have other UI to
indicate that. (And if it sucks, we need to fix it.) Eliminating the
scheme also means we could do things like show some HTTPS connections as
if they were HTTP - e.g. for self-signed certificates, which people just
use when they want eavesdropping protection - without our UI being
inconsistent. This is an improvement on the current behaviour, which is
just to throw an error.

FTP could have a special favicon, as could file://.

2) Hide username and password

If present. Usernames and passwords over unencrypted channels, embedded
in GET requests (which are cached) and links, are fundamentally insecure
and their most common use is for spoofing (although we already have some
protection against that). If people type them in, we'll use them to try
and log in, but we won't show them in the location bar.

Yes, this makes them less useful - if you make a typo, you need to
retype everything. I don't think this is a bad trade-off.

3) Highlight hostname

Take either the entire hostname or the Effective TLD + 1 and highlight
it in a button-like style. So either:

www. [EXAMPLE.COM] /foo/bar/baz?q=x

Or maybe

[www.EXAMPLE.COM] /foo/bar/baz?q=x

where capital letters indicate some sort of styling such as bold. (We
need to be careful with bold; with some fonts, it reduces the difference
between letters such as l and i, which is bad from a spoofing
perspective. Further research required.) There is some space (perhaps
half an em) either side of the button.

Clicking the hostname "button" takes you back to the root of the site -
and this would affect which of these two options we actually choose.
Consider george.blogspot.com/archive/... - do we want to go back to
george.blogspot.com or blogspot.com? Probably the former. But then that
would mean that microsoft.com.foo.bar.baz.evil.com would be all on the
button, including the microsoft.com part. Difficult.

For file URLs, you'd get:

[C:] /Program Files/Firefox/

on Windows, and

[/] home/gerv/test/

on Unix. Yes, these two are inconsistent with respect to the placement
of the initial slash. I'm not sure how to deal with that. I think a
prefix like

[My Computer] /home/gerv/test

would be horrible, particularly on Unix.

4) Display EV business name and country

For HTTPS connections with EV certificates, replace the hostname with
the O (Organisation) and C (Country) fields from the certificate. So:

[* Paypal, Inc.] /foo/bar/baz?q=x

Replacing the hostname rather than just adding to it means there's a
really big difference between the real site and an attempted spoof,
which would have a domain name in that space rather than a textual name.

The * represents a flag. We need to include information about the
country (there can be businesses of the same name in different
jurisdictions), and the question is, do we use letters (US, UK, CM) or a
flag? A flag is safe because we are actually talking about countries,
not languages, and it might be more recognisable and differentiable. IE
and Opera are using letters.

The flag is next to where the favicon should be, which raises a risk of
confusing of spoofing, but leads on to:

5) Remove the favicon from the URL bar entirely

We would keep it on tabs, of course. I realise this is controversial;
here's my rationale. Favicons in the URL bar are dangerous, because they
represent the website having some control over what's in the chrome.
This is why we turned off website access to the status bar. We already
have spoof websites having a little lock as their favicon, to try and
persuade users they are over SSL. Let's put the websites back into the
content area box.

This would probably imply making the tab bar always visible - i.e.
setting browser.tabs.autoHide to false - so that the favicon was always
visible. I think this is good because it improves the discoverability of
tabs and stops the content area jumping around when you go from one to
two tabs or vice versa. I don't know if the default setting of this
preference is a controversial issue.

I believe that the only other function of the page-proxy-icon (where the
favicon appears) is to be draggable to create e.g. bookmarks toolbar
entries; that role could be taken over by the domain name button,
perhaps. I admit there's further thinking to do here.

6) Focus turns bar back to a text box

On focus, move back towards being a text box. People have important
behaviours to do with URL bar hand-editing that we don't want to break.
Therefore, clicking anywhere in the URL bar (except on the domain
button) or pressing Ctrl-L, focusses the URL bar and makes the following
changes.

The 3D-ness of the domain button becomes faded and 2-D - so the
separation is still visible, but the URL now looks flat. The URL bar
acts as much like a single text box as possible. The spaces between
different parts remain (to keep the text stable; the text must
absolutely not move on focus, otherwise the caret appears somewhere
different from where you clicked) but if you select and copy, the spaces
don't appear.

7) Change selection behaviour

People edit individual URL components. So, we should make it easier to
select individual components. Like in a word-processor, a single-click
focusses, a double-click selects a component ("word") - hostname, path
segment, URL parameter key+value or fragment identifier, and a
triple-click selects the entire URL (equivalent to "select line").

Again, I don't know if this is a can of worms - I suspect URL bar
selection behaviour has been discussed before.

8) Analyse font choice carefully

If we are emboldening some parts of the URL (e.g. the domain), we need
to be very careful about choosing fonts where the bold version provides
enough differentiation between visually close letters like i and
l.Perhaps we might consider a fixed-width font in the URL bar? This
would also make selection easier; at the moment, putting the caret in
the right place in million.com is nearly impossible for those with less
than perfect motor skills, and tricky even for those with.


Not all of these suggestions are interrelated; some could be removed
without affecting others. This is not supposed to be a tightly-bound
take-it-or-leave-it package.

Gerv

Mardak

unread,
Feb 15, 2007, 10:57:31 PM2/15/07
to
On Feb 15, 12:19 pm, Gervase Markham <g...@mozilla.org> wrote:
> 3) Highlight hostname

> Clicking the hostname "button" takes you back to the root of the site -

I agree that the hostname should be the primary focus, but why limit
the "button" aspect to just the root? Vista has an interesting take on
path/breadcrumbs [1] where you can click individual components to jump
to that location.

[[www.EXAMPLE.COM]] / [foo] / [bar] / [baz]?q=x

Clicking www.EXAMPLE.COM takes you to http://www.example.com/
Clicking on foo takes you to http://www.example.com/foo/
Clicking on baz takes you to http://www.example.com/foo/bar/baz


> 7) Change selection behaviour
> People edit individual URL components. So, we should make it easier to
> select individual components.

Another feature that Vista provides is the ability to switch to an
ancestor's sibling [2] of the current location. It's slightly
different for a file explorer where you know exactly what's available,
but the possible choices would be populated from history (and links on
the current page.)

[[weblogs.mozillazine.org]] [/] [gerv] [/] [archives] [/] [2007] [/]
[02] [/] [location_bar_proposal.html]

Clicking on the rightmost [/] could show "perspective.html".
Clicking the leftmost [/] could show "asa", "roadmap", etc.


The examples I've given in text and from Vista probably aren't the
best UI solutions for these features. Some simple modifications for
the web could be to only show the "button" if the user has previously
visited that non-root-ancestor.

The main idea is letting the user easily jump to related pages from
the current URL.

[1] http://www.winsupersite.com/images/reviews/winvista_rtm_5_32.jpg
[2] http://www.winsupersite.com/images/reviews/winvista_rtm_5_33.jpg

--
Ed

Mark Finkle

unread,
Feb 15, 2007, 11:25:47 PM2/15/07
to
Gerv,

I have been using the Locationbar^2 extension, which appears to be
tracking bug 366797. Here's some feedback based on using it and from
your proposal:

* I agree with all of your stated goals, except the "Make common
operations easier" should be optional IMO. I believe typical web users
do very little operations on the URL. The rest of your goals are
important to me as well and will benefit users.

* After installing the extension, it was weird to see the URL address
change from the familiar plaintext string to the slightly-formatted
style. It didn't take long before I was quite comfortable with it and I
have come to use it when scanning URLs.

* I do not believe the button-style is required and I feel it creates
too much "noise" in the URL bar.

* I know that Linux (and now Vista) use the button metaphor when
browsing files and folders. That might make sense for situations where
jumping between folders is the typical action, but I don't believe that
is the typical action for URLs. Navigation is more commonly done through
links on the page not in the URL bar.

Some of your other points are good to discuss, but are less critical to
the stated goals. Displaying EV business name and country is probably
too much for me, but I'd be fine with dropping the favicon. Special
selection is nice, but not critical and may be a pain to get right.

Through my use of various versions of the Locationbar extension, I'd say
my ranked preferred styles are:

1. Format URL (hide scheme + highlight hostname), except when URL bar
has focus or on mouseover. The mouseover condition makes it easy to
click into the URL and start editing. (version 0.5 I think)

2. Format URL (hide scheme + highlight hostname), except when URL bar
has focus. The hostname is a link that goes to the root of the site. The
link approach minimizes the visual clutter. (version 0.6 I think)

Any approach with buttons, as you propose or as seen in Locationbar
0.7+), just adds too much clutter for too little payoff.

I guess I should also say that there should be an option to revert to
the current style as well.

Thanks,
Mark

Gervase Markham wrote:
> Goals:
>
> - Don't break stuff people use
> - Make the hostname stand out more to reduce spoofing
> - Reduce the risk of spoofing in other ways
> - Make the contents of the URL bar more understandable
> - Make common operations easier
>
> Optional Goal:
>
> - Find a way of presenting information from EV certificates
>
> Suggested Changes:
>
> 1) Hide the scheme
>

> 2) Hide username and password
>

> 3) Highlight hostname


>
> 4) Display EV business name and country
>

> 5) Remove the favicon from the URL bar entirely
>

> 6) Focus turns bar back to a text box
>

> 7) Change selection behaviour

Tony Mechelynck

unread,
Feb 15, 2007, 11:39:58 PM2/15/07
to
Gervase Markham wrote:
[...]

> - Don't break stuff people use
[...]

> Suggested Changes:
>
> 1) Hide the scheme
>
> The scheme (e.g. "http://", "ftp://") should be hidden permanently for
> HTTP, HTTPS, FTP and file URLs. The differences between HTTP and FTP
> have long since ceased to matter to the average web user. The difference

I'm not so sure of that. It is true that
http://ftp.mozilla.org/pub/mozilla.org/ and
ftp://ftp.mozilla.org/pub/mozilla.org/ (with anonymous FTP) access exactly the
same folder on the same machine, but that is not true in all cases: for
instance, my user site is either http://users.skynet.be/antoine.mechelynck/
(read-only, and when giving a directory name you get the index.htm if it
exists, otherwise an error page) or ftp://users.skynet.be/ (read-write, with
username and password, no "username" directory, and when giving a directory
name I get a directory listing).

In addition, I like the possibility of copying the URI from the Location Bar
to the clipboard in order to access the same page in a different browser (be
it another Mozilla browser or a non-Mozilla browser such as IE or Konqueror),
or to paste the URI in an email.

> between HTTP and HTTPS is, of course, important, but we have other UI to
> indicate that. (And if it sucks, we need to fix it.) Eliminating the
> scheme also means we could do things like show some HTTPS connections as
> if they were HTTP - e.g. for self-signed certificates, which people just
> use when they want eavesdropping protection - without our UI being
> inconsistent. This is an improvement on the current behaviour, which is
> just to throw an error.
>
> FTP could have a special favicon, as could file://.

[...]

Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
36. You miss more than five meals a week downloading the latest games from
Apogee.

Dao Gottwald

unread,
Feb 16, 2007, 12:16:55 AM2/16/07
to
> FTP could have a special favicon, as could file://.

For file:// only if it's a directory listening, as a document can have
its own icon.

> 2) Hide username and password

That should already be the case.

> I think a prefix like
>
> [My Computer] /home/gerv/test
>
> would be horrible, particularly on Unix.

Why?

> 4) Display EV business name and country
>
> For HTTPS connections with EV certificates, replace the hostname with
> the O (Organisation) and C (Country) fields from the certificate.

I think that goes too far away from the URL semantics. Domains are still
quite important to users. Even though you can type "paypal inc." into
the location bar for getting to paypal.com, that might fail in other cases.


Regards, Dao

Asrail

unread,
Feb 16, 2007, 1:34:34 AM2/16/07
to
Gervase Markham, 15-02-2007 15:19:

>
> Goals:
>
> - Don't break stuff people use

It's a great point.

> - Make the hostname stand out more to reduce spoofing
> - Reduce the risk of spoofing in other ways
> - Make the contents of the URL bar more understandable

Another one.

> - Make common operations easier

It's superfluous and usable only when don't breaking anything else.

>
> Suggested Changes:
>
> 1) Hide the scheme
>
> The scheme (e.g. "http://", "ftp://") should be hidden permanently for
> HTTP, HTTPS, FTP and file URLs. The differences between HTTP and FTP
> have long since ceased to matter to the average web user.

> [snip]


> FTP could have a special favicon, as could file://.

I would like it. As another user mentioned, the content for ftp/http
might be different. I would like to quickly know where I am (from your
fully proposal it's very hard).
Well... maybe both http and ftp are directory listings and only the
content changes.

> [snip]


>
> 3) Highlight hostname
>
> Take either the entire hostname or the Effective TLD + 1 and highlight
> it in a button-like style. So either:
>
> www. [EXAMPLE.COM] /foo/bar/baz?q=x
>
> Or maybe
>
> [www.EXAMPLE.COM] /foo/bar/baz?q=x
>
> where capital letters indicate some sort of styling such as bold. (We
> need to be careful with bold; with some fonts, it reduces the difference
> between letters such as l and i, which is bad from a spoofing
> perspective. Further research required.) There is some space (perhaps
> half an em) either side of the button.

The bold issue is something we should pay a lot of attention. Colors
alone are not a good thing also.

> Clicking the hostname "button" takes you back to the root of the site -
> and this would affect which of these two options we actually choose.
> Consider george.blogspot.com/archive/... - do we want to go back to
> george.blogspot.com or blogspot.com? Probably the former. But then that
> would mean that microsoft.com.foo.bar.baz.evil.com would be all on the
> button, including the microsoft.com part. Difficult.

That's confusing. including microsoft.com on the button is agains one of
the main goals, it will make spoofing easier.
But probably the user would want to go to the subdomain, not the main
one. Maybe changing something on mouseover (since the user only will
mouseover when he's going to click).

> For file URLs, you'd get:
>
> [C:] /Program Files/Firefox/
>
> on Windows, and
>
> [/] home/gerv/test/
>
> on Unix. Yes, these two are inconsistent with respect to the placement
> of the initial slash. I'm not sure how to deal with that. I think a
> prefix like
>
> [My Computer] /home/gerv/test
>
> would be horrible, particularly on Unix.

"My Computer" is windows-ish, argh. I wouldn't complain about "root
filesystem" (it's what most file managers use).

> 4) Display EV business name and country

> [snip]

I don't think it's really needed by default. A "Micros Soft Cooporation"
on Jamaica could confuse someone, anyway.

>
> 5) Remove the favicon from the URL bar entirely
>
> We would keep it on tabs, of course. I realise this is controversial;
> here's my rationale. Favicons in the URL bar are dangerous, because they
> represent the website having some control over what's in the chrome.
> This is why we turned off website access to the status bar. We already
> have spoof websites having a little lock as their favicon, to try and
> persuade users they are over SSL. Let's put the websites back into the
> content area box.

Would be good to use the area of the favicon for another useful info and
they really allow spoofing.

> This would probably imply making the tab bar always visible - i.e.
> setting browser.tabs.autoHide to false - so that the favicon was always
> visible. I think this is good because it improves the discoverability of
> tabs and stops the content area jumping around when you go from one to
> two tabs or vice versa. I don't know if the default setting of this
> preference is a controversial issue.

I don't think you loose too much setting it to false.

> I believe that the only other function of the page-proxy-icon (where the
> favicon appears) is to be draggable to create e.g. bookmarks toolbar
> entries; that role could be taken over by the domain name button,
> perhaps. I admit there's further thinking to do here.

We could have a icon representing a web-page, another one for a secure
web-page, another for remote files, another for local files (maybe one
for each protocol or to stick with a default one).

> 6) Focus turns bar back to a text box
>
> On focus, move back towards being a text box. People have important
> behaviours to do with URL bar hand-editing that we don't want to break.
> Therefore, clicking anywhere in the URL bar (except on the domain
> button) or pressing Ctrl-L, focusses the URL bar and makes the following
> changes.
>
> The 3D-ness of the domain button becomes faded and 2-D - so the
> separation is still visible, but the URL now looks flat. The URL bar
> acts as much like a single text box as possible. The spaces between
> different parts remain (to keep the text stable; the text must
> absolutely not move on focus, otherwise the caret appears somewhere
> different from where you clicked) but if you select and copy, the spaces
> don't appear.

Please, I wanna my protocol.
I complained about it before testing the extension and I've seen you saw
it on mouseover. Is every time worse to get it and your way it's impossible.
So we would loose the ability to copy the whole URL, including the protocol.

I understand the issue with moving the focus, but we have another ways
of treating it.
Well... the protocol could be very, very, very transparent, but visible,
for instance. It wouldn't be confused with the URL but the change to a
plain view would sucks less.

I'm strongly against to not showing the protocol while editing the URL.
The user could want to copy'n'past the URL to the friend and that
wouldn't work! (assuming some servers and their ftp configuration, for
instance)


> 7) Change selection behaviour
>
> People edit individual URL components. So, we should make it easier to
> select individual components. Like in a word-processor, a single-click
> focusses, a double-click selects a component ("word") - hostname, path
> segment, URL parameter key+value or fragment identifier, and a
> triple-click selects the entire URL (equivalent to "select line").

How do you select the hostname clicking it while it's a button that will
execute some action when clicked :D? (Changing from "clearly a button"
to "is it a button?" on mouseover is bad)

Well... I liked a lot this way. It would be easy to still working the
way the people do today, if desired.
Mark Finkle made me discover today I'm not an average user (the kind of
user never uses the mouse to edit URLs, so most of the things here don't
apply to me, anyway), but we shouldn't break features that work for a
lot of people, even if it's only 3 or 5%. Even if someone almost never
do something while using the browser, but the UI looks like a ordinary
edit box, it should do what is expected from it.
For instance:
- the user should be able to click and drag to select a portion of the
URL, instead of click and release and click again later and drag
- the user should be able to select a part of the hostname to modify
(he couldn't achieve this if it's linkified)

> Again, I don't know if this is a can of worms - I suspect URL bar
> selection behaviour has been discussed before.

And we arrived where?
Correct me if wrong, but from your proposal, if I typed
aVeryLongLongLongImenseUrl.aGreatDomain.com with a little mistake I
would have to type it all over again (and I could make another mistake).

> 8) Analyse font choice carefully
>
> If we are emboldening some parts of the URL (e.g. the domain), we need
> to be very careful about choosing fonts where the bold version provides
> enough differentiation between visually close letters like i and
> l.Perhaps we might consider a fixed-width font in the URL bar? This
> would also make selection easier; at the moment, putting the caret in
> the right place in million.com is nearly impossible for those with less
> than perfect motor skills, and tricky even for those with.

The user should be able to choose the font he wants.
At Linux, for instance, with gtk2, every user expects the gtk2 programs
to use their gtk2 fonts on the interface, except he stated otherwise.
Why should FX to be different?
So fixed-width/monospace font looks like a good option (OK, it looks not
so pretty, but...).

> Not all of these suggestions are interrelated; some could be removed
> without affecting others. This is not supposed to be a tightly-bound
> take-it-or-leave-it package.

Neither are my comments ;).
Don't take me much serious.

Dao Gottwald

unread,
Feb 16, 2007, 8:09:06 AM2/16/07
to
Asrail wrote:
> Mark Finkle made me discover today I'm not an average user (the kind of
> user never uses the mouse to edit URLs, so most of the things here don't
> apply to me, anyway), but we shouldn't break features that work for a
> lot of people, even if it's only 3 or 5%. Even if someone almost never
> do something while using the browser, but the UI looks like a ordinary
> edit box, it should do what is expected from it.
> For instance:
> - the user should be able to click and drag to select a portion of the
> URL, instead of click and release and click again later and drag
> - the user should be able to select a part of the hostname to modify
> (he couldn't achieve this if it's linkified)

Let me quote the related part our IRC conversation, so that everybody
knows about it:

<asrail> Clickin on a token and selecting it is nice, but that shouldn't
broke click and drag selection, for instance
<dao> the idea is that you don't have to drag that often
<asrail> Should the user to receive a penalty of two clicks for this?
<asrail> Something we should remember is that the our average user does
not read pmo, neither our wiki or look at bugzilla
<asrail> A good browser for us might to be a geeky one for them
<dao> he'll just notice when clicking
<dao> and the penalty is worthwhile when it saves clicks for more other
cases

I don't think we can evolve the location bar as aggressively as Gerv
proposed or as I've implemented it and still have 100% parity with a
legacy textbox. We will have to make trade-offs. And we shouldn't be
scared of 3% complaining about an extra click if 30% applaud.

JP. Baker

unread,
Feb 16, 2007, 9:34:56 AM2/16/07
to
In article <u9ydnR5N2tHTr0jY...@mozilla.org>,

Mark Finkle <mark....@gmail.com> wrote:
>* After installing the extension, it was weird to see the URL address
>change from the familiar plaintext string to the slightly-formatted
>style. It didn't take long before I was quite comfortable with it and I
>have come to use it when scanning URLs.

I think I am going to have to second this; Reading the posts, I thought
it sounded like a horrible idea but, about five minutes after installing
0.7.2 I was already quite liking it [*].

It will take a bit more experimentation as I have an undiagnosed issue with
Firefox 2 not always showing a site as secure [I think it is some combination
of Frames, Cache, bfcache and possibly caching secure pages] that I will need
to check doesn't occur in Firefox 3.

John

[*] After all it is very similar to the breadcrumbs that I put on our sites:

University home > News > News from around the Uni. > The past fortnight's news from .

www.bris.ac.uk > news > university > recent.html
--
John P Baker

Robert Kaiser

unread,
Feb 16, 2007, 9:53:23 AM2/16/07
to
Dao Gottwald schrieb:

>> I think a prefix like
>>
>> [My Computer] /home/gerv/test
>>
>> would be horrible, particularly on Unix.
>
> Why?

Maybe because
[My Computer] /mnt/srv/software/
would be on a server elsewhere and not actually my computer here on my
system?
Additionally, it takes away space and is of no practical use.

The root of the file system is just "/" in unix-ish systems, and I don't
think inventing words for that makes a lot of use. "file://" is as good
or bad as "My computer".

Robert Kaiser

Michael Lefevre

unread,
Feb 16, 2007, 9:58:25 AM2/16/07
to
On 2007-02-15, Gervase Markham <ge...@mozilla.org> wrote:
[snip]

> The scheme (e.g. "http://", "ftp://") should be hidden permanently for
> HTTP, HTTPS, FTP and file URLs. The differences between HTTP and FTP
> have long since ceased to matter to the average web user. The difference
> between HTTP and HTTPS is, of course, important, but we have other UI to
> indicate that. (And if it sucks, we need to fix it.)

That UI though, whether it sucks or not, isn't something that people
usually use to distinguish between different sites. I guess that could be
changed, but it seems like you'd have to educate the user in weird ways
that would actually take away from efforts to make people understand
security.

Take your own host for example - I could have "www.gerv.net" in the URL
bar, and either be at your webpage, or at a blackcatnetworks page, or
being given a login prompt for FTP. If you take that away from the URL
bar, you are effectively going to force everyone to have 1 service per
hostname, or to ensure that FTP, HTTP and HTTPS are all pointing to the
same content.

> Eliminating the
> scheme also means we could do things like show some HTTPS connections as
> if they were HTTP - e.g. for self-signed certificates, which people just
> use when they want eavesdropping protection - without our UI being
> inconsistent.

What happens when there is a host called wibble.example.com, and it runs
an intranet on http and a webmail service on https, with a self-signed
cert. The UI would be consistent (indeed, identical), but the content
would be completely different.

I don't imagine this matters in terms of Paypal, Ebay, as they will have
everything on different host names. But in smaller settings, there may
well be 1 host name with a bunch of different services, and they would be
confusing and spoofable. For example, I could set up some HTML pages on
an FTP server on a host which was running the organisation's intranet, and
make it look like I'd replaced the intranet with my web pages.

[snip]


> [* Paypal, Inc.] /foo/bar/baz?q=x
>
> Replacing the hostname rather than just adding to it means there's a
> really big difference between the real site and an attempted spoof,
> which would have a domain name in that space rather than a textual name.

But it could mean for a radically different hostname, you have a similar
textual name. If someone gets an EV certificate for Manybank Inc, they
can host their site at https://kjasdffdsfjewf.evil.com and the URL bar
will be almost identical to the genuine site of Anybank Inc.

> A flag is safe because we are actually talking about countries,
> not languages, and it might be more recognisable and differentiable. IE
> and Opera are using letters.

I guess that would have to be examined, but I think I'd be more easily
able to recognise and distinguish countries by letters than by a 16-pixel
or so wide version of a flag. I guess for this purpose I only really need
to recognise my own country flag and the flag of a country I'm likely to
be doing a lot of business with, and recognise any other flag as
"something else".

> 6) Focus turns bar back to a text box
>
> On focus, move back towards being a text box. People have important
> behaviours to do with URL bar hand-editing that we don't want to break.

How would this fit together with replacing the hostname with the
certificate name? Would it switch back to showing the hostname when
focused? Or would we be happy to completely break the stuff you discuss
here for sites with EV?

--
Michael

Dao Gottwald

unread,
Feb 16, 2007, 10:08:12 AM2/16/07
to
Robert Kaiser wrote:
> Maybe because
> [My Computer] /mnt/srv/software/
> would be on a server elsewhere and not actually my computer here on my
> system?

There's nothing wrong with that. The starting point is still your file
system ("/" alias "my computer").

> "file://" is as good or bad as "My computer".

For geeks, yes.

Gervase Markham

unread,
Feb 16, 2007, 10:32:36 AM2/16/07
to
Gervase Markham wrote:
> The blog version of this proposal takes advantage of HTML formatting
> and has some crude mockups, so might be easier to read:
> http://weblogs.mozillazine.org/gerv/archives/2007/02/location_bar_proposal.html

Several people commented on the blog version; here's my response to the
first set of comments, so hopefully they can continue the discussion here.

Several people, both on the blog and here, have mentioned making all the
path components clickable buttons, instead of just the domain. This is a
common question, so I've posted my response as a separate message.

Heikki said:
> My biggest fear is with replacing the host with business name and
> country. Most companies own different hosts, in completely different
> domain names. I think there can be cases where it matters to the user
> to know which host they are connected to, not just which company.

Can you give an example of where the user would care about which host
they were connected to, as long as it were one owned by the correct
company? I know I certainly don't care if my Google search results are
served by www.l.google.com or www.q.google.com.

> I also have a question about the port number. Currently mozilla
> security model considers scheme + host + port to identify a website.
> Theoretically you can have a different entity controlling
> example.com:80 and example.com:90.

I'm not completely sure what to do about the port number. I agree that
it's theoretically possible that two entirely different entities could
control port 80 and port 90; but it is certainly unusual.

Karl said:
> 1. Will every Google service be showing "(flag) Google, Inc"? While
> good for security, it'd be harder to distinguish the services without
> knowing the service icon (if the service has one).

Surely you distinguish between Google services by, er, looking at the
content area? :-) Copy/pasting should work as now; when you focus the
URL bar, it turns back to a text box.

Voracity suggested:
> Why can't you divide the URL bar, like this?
> http://voracity.org/images/testurlbar2.png

I'm not sure how we could implement this proposal without terminally
confusing people. While it's nice to be able to have your cake and eat
it, I'm not sure we can in this case.

J. Ruigrok van der Werven said:
> Cutesy flags for a company do nothing to put trust to a site in my
> opinion. Especially not if it is a company with presence in various
> countries and using centralised certificates, thus causing a
> non-match between flag of the parent for a TLD you entered.

The flags are not supposed to inspire trust; they are supposed to part
of the representation of the underlying reality that the website
identity is more strongly known than with normal certificates (and that
the company concerned has the name displayed, and lives in that
country). Which flag they get depends on where they applied for the
cert; if they feel having all the certs have the same flag will cause
confusion, they can apply for certs in different countries.

> Using bold might be cute for latin-based/derived languages, it
> totally messes up fonts for Asian languages and possibly others due
> to strokes becoming thicker and in some cases omitted to preserve the
> form.

I agree that the method of domain emphasis may have to vary based on
locale. Which is not ideal. We may just drop the bold entirely, and rely
on the button surround to pick out the name. How do you do emphasis in
Kanji? Underlining?

Gerv

Gervase Markham

unread,
Feb 16, 2007, 10:32:39 AM2/16/07
to
Gervase Markham wrote:
> 3) Highlight hostname
>
> Take either the entire hostname or the Effective TLD + 1 and highlight
> it in a button-like style. So either:

Several people, both on the blog and here in the newsgroup, have

mentioned making all the path components clickable buttons, instead of

just the domain. This is a fairly common suggestion, and I almost
addressed it in the original post. I'm doing so now, in a new thread part.

I'm wary of such an approach, for the following reasons:

* You don't know if moving up directories will actually produce a
meaningful page. On good websites it does, but not all websites are
good. More research may be needed, but adding a load of buttons to the
interface which take people to a 404 or a 500 probably isn't good UI
design.

* If all the path components are buttoned, then there's nowhere you can
click to focus the URL bar and turn it into a text box.

* One reason this works well in e.g. file managers is that they know all
the possible options for a path component, and can present them in a
dropdown. We don't in most cases.

Gerv

Gervase Markham

unread,
Feb 16, 2007, 10:34:11 AM2/16/07
to
Mardak wrote:
> On Feb 15, 12:19 pm, Gervase Markham <g...@mozilla.org> wrote:
>> 3) Highlight hostname
>> Clicking the hostname "button" takes you back to the root of the site -
>
> I agree that the hostname should be the primary focus, but why limit
> the "button" aspect to just the root?

Good question. I've posted a separate message in this thread addressing
this exact issue.

>> 7) Change selection behaviour
>> People edit individual URL components. So, we should make it easier to
>> select individual components.
>
> Another feature that Vista provides is the ability to switch to an
> ancestor's sibling [2] of the current location. It's slightly
> different for a file explorer where you know exactly what's available,
> but the possible choices would be populated from history (and links on
> the current page.)

But how would you avoid giving the impression that these are the only
choices available?

> The examples I've given in text and from Vista probably aren't the
> best UI solutions for these features. Some simple modifications for
> the web could be to only show the "button" if the user has previously
> visited that non-root-ancestor.

I'm not sure that users would easily understand why sometimes they got a
button and sometimes they didn't.

> The main idea is letting the user easily jump to related pages from
> the current URL.

Isn't that what in-page navigation is supposed to do? :-)

Gerv

Robert Kaiser

unread,
Feb 16, 2007, 10:36:03 AM2/16/07
to
Gervase Markham schrieb:

> - Make common operations easier

A common operation for me is to edit the domain name and look at the
same URL on a different domain, as I'm maintaining a bunch of sites
using the same system and using the same path/querystring parts of their
URLs on different domains.

It's clear such a restructuring can't (easily) satisfy everyone, but I'd
be happy to e.g. be able to correct a mistyped URL fast, even if I
mistyped the domain part. And, from your proposal, I couldn't yet find
out how to get to an empty location bar in which I can type a new URL,
or search query.

Ah, yes, that leads me to the next idea/problem: I love typing a bunch
of words in the location bar and have SeaMonkey automatically search
Google (my default search engine) for those, not needing a special
"search" textbox in the toolbar. It's not that hard to detect if what
the user entered is a URL or not :)

I'd hope that we could get to some stage where we have one place in the
UI where a user would enter "what he wants to see/find" and we would
perform the right action based on circumstances. That action could be
"request the entered URL", "search the web for this expression" or even
"search the currently viewed page for this expression". I believe that
could be done from one central place in the UI, the location bar being
the obvious candidate for that in my eyes. Maybe the bar would need to
visibly enter different modes of operation or so for that, but I think
it should be tried, as it really would ease user interaction with the
browser, IMO.

That said, icons are nice for many things, but please take into account
that there are people who have a hard time seeing different colors,
seeing details in small icons or even seeing graphics at all (and even
people with full eyesight might need to deal with low-color displays or
small resolutions). We need to provide meaningful text for those. A
yellow color of the bar or a small lock icon in some unrelated part of
UI are really hard to see in some cases.

That and the difference between HTTP and FTP in some common cases makes
me think instead of removing the protocol, we should just display it
differently, e.g. replace "http://" with something that says "Web:" or
so, "https://" could get "Web (secure):", "ftp://" could be converted to
"FTP:" or "Remote file:", then "file://" could be "Local file:" - in
this case, we could even leave favicons in (and use some nice favicons
for ftp/file), as "[file icon] Local file: /home/robert/" is far enough
from a spoofed "[file icon] Web: fakehome.com /robert/" or such.

Along with all that, a new vision begins to form in my mind: this could
allow simple path editing as in your proposal, and for many use cases
that would work fine.
With some user action (edit icon or such?) to start editing the full
URL, we could switch the bar into edit mode, displaying a dropdown with
a current value of "URL:" instead of the protocol identifier string I
proposed in the last paragraph, and the full URL for simple editing as
in the current location bar. The dropdown would be changeable to "Search
the Web" or "Find in page", each of which would clear the space for
editing and allow the user to either enter a web search or do a FAYT
operation on the current page. Of course, any current way of invocation
of those functions currently would switch into the respective edit mode
(Ctrl+F, Ctrl+L, etc.) - and ESC or small cancel icon in the bar would
leave edit/search mode and go back to normal display.

I think there's clearly some room for improvement of the location bar,
and that open discussion might lead us to a really powerful widget after
all :)

Robert Kaiser

Gervase Markham

unread,
Feb 16, 2007, 10:37:02 AM2/16/07
to
Mark Finkle wrote:
> * I agree with all of your stated goals, except the "Make common
> operations easier" should be optional IMO. I believe typical web users
> do very little operations on the URL.

I'd be interested if anyone has any hard figures here. My gut tells me
that clearing out the URL and replacing it with something else would be
pretty common, but most other operations would be advanced.

> * I do not believe the button-style is required and I feel it creates
> too much "noise" in the URL bar.

You feel the bolding is sufficient? The problem with bolding is that it
doesn't work well for some scripts (e.g. Chinese).

> 1. Format URL (hide scheme + highlight hostname), except when URL bar
> has focus or on mouseover. The mouseover condition makes it easy to
> click into the URL and start editing. (version 0.5 I think)

Changing the styling on mouseover might mean we couldn't do the
clickable button. Unless it only changed on mouseover of the rest of the
URL.

> Any approach with buttons, as you propose or as seen in Locationbar
> 0.7+), just adds too much clutter for too little payoff.

I agree for the non-domain-name buttons, FWIW.

Gerv

Gervase Markham

unread,
Feb 16, 2007, 10:40:26 AM2/16/07
to
Tony Mechelynck wrote:
> I'm not so sure of that. It is true that
> http://ftp.mozilla.org/pub/mozilla.org/ and
> ftp://ftp.mozilla.org/pub/mozilla.org/ (with anonymous FTP) access
> exactly the same folder on the same machine, but that is not true in all
> cases: for instance, my user site is either
> http://users.skynet.be/antoine.mechelynck/ (read-only, and when giving a
> directory name you get the index.htm if it exists, otherwise an error
> page) or ftp://users.skynet.be/ (read-write, with username and password,
> no "username" directory, and when giving a directory name I get a
> directory listing).

I'm not arguing that there is no difference between a machine accessed
over HTTP and FTP; I'm arguing that a web user doesn't really care which
one he's using when he clicks a link to go there. The readable vs.
writable thing doesn't matter for a browser, which doesn't offer FTP
writing facilities.

The differences in behaviour (WRT, for example, index.html) are, I
suggest, understood by those who understand them, and not really noticed
by those who don't.

> In addition, I like the possibility of copying the URI from the Location
> Bar to the clipboard in order to access the same page in a different
> browser (be it another Mozilla browser or a non-Mozilla browser such as
> IE or Konqueror), or to paste the URI in an email.

Absolutely. We wouldn't want to break that. See point 6.

Gerv

Gervase Markham

unread,
Feb 16, 2007, 10:46:52 AM2/16/07
to
Dao Gottwald wrote:
>> FTP could have a special favicon, as could file://.
>
> For file:// only if it's a directory listening, as a document can have
> its own icon.

Hmm. Yes, we might well be able to do that.

>> 2) Hide username and password
>
> That should already be the case.

Do we do this already? Cool.

>> I think a prefix like
>>
>> [My Computer] /home/gerv/test
>>
>> would be horrible, particularly on Unix.
>
> Why?

"My Computer" or similar words are such a Windows-ism. They certainly
make me recoil in horror. I might buy "Root", but that might be a bit
techie.

>> 4) Display EV business name and country
>>
>> For HTTPS connections with EV certificates, replace the hostname with
>> the O (Organisation) and C (Country) fields from the certificate.
>
> I think that goes too far away from the URL semantics. Domains are still
> quite important to users.

That's a very big generalisation. Domains are important in the sense
that you want to be able to type one in, and they are important for
knowing where you are - but the idea of EV is that it provides a more
sure way of telling where you are. After all, anyone can register
www.paypal-payments.com, but the idea is that no-one apart from Paypal,
Inc. in the US can get an EV cert saying Paypal, Inc. (US).

> Even though you can type "paypal inc." into
> the location bar for getting to paypal.com, that might fail in other cases.

I'm not suggesting we do anything extra to enable this sort of thing.

Gerv

Gervase Markham

unread,
Feb 16, 2007, 10:55:32 AM2/16/07
to
Asrail wrote:
> I don't think it's really needed by default. A "Micros Soft Cooporation"
> on Jamaica could confuse someone, anyway.

No more, and hopefully a lot less, than www.micros0ft.com.

> I don't think you loose too much setting it to false.

http://wwwnew.towson.edu/ows/lose_lose.htm :-)

>> I believe that the only other function of the page-proxy-icon (where
>> the favicon appears) is to be draggable to create e.g. bookmarks
>> toolbar entries; that role could be taken over by the domain name
>> button, perhaps. I admit there's further thinking to do here.
>
> We could have a icon representing a web-page, another one for a secure
> web-page, another for remote files, another for local files (maybe one
> for each protocol or to stick with a default one).

What, where the favicon now is? I'm not sure this icon would add much
value. Those protocols that don't provide a favicon can have a standard
icon in the same place (on the tabs), but I don't see much value in an
icon telling you "this is a web page". And of course we have other UI to
tell you "this is a secure web page".

>> The 3D-ness of the domain button becomes faded and 2-D - so the
>> separation is still visible, but the URL now looks flat. The URL bar
>> acts as much like a single text box as possible. The spaces between
>> different parts remain (to keep the text stable; the text must
>> absolutely not move on focus, otherwise the caret appears somewhere
>> different from where you clicked) but if you select and copy, the
>> spaces don't appear.
>
> Please, I wanna my protocol.

Why? Just so you can copy it, or for some other reason also?

> I complained about it before testing the extension and I've seen you saw
> it on mouseover. Is every time worse to get it and your way it's
> impossible.
> So we would loose the ability to copy the whole URL, including the
> protocol.

Hmm. It is going to be hard to square the circle of "hide some stuff",
"allow copying of everything" and "don't make stuff move when you focus
the URL bar"...

>> 7) Change selection behaviour
>>
>> People edit individual URL components. So, we should make it easier to
>> select individual components. Like in a word-processor, a single-click
>> focusses, a double-click selects a component ("word") - hostname, path
>> segment, URL parameter key+value or fragment identifier, and a
>> triple-click selects the entire URL (equivalent to "select line").
>
> How do you select the hostname clicking it while it's a button that will
> execute some action when clicked :D? (Changing from "clearly a button"
> to "is it a button?" on mouseover is bad)

Good point.

>> Again, I don't know if this is a can of worms - I suspect URL bar
>> selection behaviour has been discussed before.
>
> And we arrived where?
> Correct me if wrong, but from your proposal, if I typed
> aVeryLongLongLongImenseUrl.aGreatDomain.com with a little mistake I
> would have to type it all over again (and I could make another mistake).

No; once the URL bar is focussed, you can edit the domain name.

> The user should be able to choose the font he wants.
> At Linux, for instance, with gtk2, every user expects the gtk2 programs
> to use their gtk2 fonts on the interface, except he stated otherwise.
> Why should FX to be different?

Because perhaps, for example, the default GTK font produces a security
risk by not differentiating enough between certain characters? Or
perhaps it doesn't have glyphs for certain characters?

Gerv

Dao Gottwald

unread,
Feb 16, 2007, 11:00:43 AM2/16/07
to
Gervase Markham wrote:
>> For file:// only if it's a directory listening, as a document can have
>> its own icon.
>
> Hmm. Yes, we might well be able to do that.

Definitely, since directory listing is already a special case anyway.

> That's a very big generalisation. Domains are important in the sense
> that you want to be able to type one in, and they are important for
> knowing where you are - but the idea of EV is that it provides a more
> sure way of telling where you are. After all, anyone can register
> www.paypal-payments.com, but the idea is that no-one apart from Paypal,
> Inc. in the US can get an EV cert saying Paypal, Inc. (US).

I got your point about security.

>> Even though you can type "paypal inc." into the location bar for
>> getting to paypal.com, that might fail in other cases.
>
> I'm not suggesting we do anything extra to enable this sort of thing.

What I meant is, if we occasionally replace the domain, a user could
think that the EV business name is an equivalent, which it isn't.

Gervase Markham

unread,
Feb 16, 2007, 11:03:44 AM2/16/07
to
Michael Lefevre wrote:
> Take your own host for example - I could have "www.gerv.net" in the URL
> bar, and either be at your webpage, or at a blackcatnetworks page, or
> being given a login prompt for FTP. If you take that away from the URL
> bar, you are effectively going to force everyone to have 1 service per
> hostname, or to ensure that FTP, HTTP and HTTPS are all pointing to the
> same content.

I don't think that follows. I'm not saying people aren't allowed to type
or link to URLs which have a scheme!

It's true that you could have two windows where the URL bar looks the
same but the content displayed is different (because you are using a
different protocol). I don't think that's necessarily a showstopper;
there's not a security risk because they are all on the same host.

>> Eliminating the
>> scheme also means we could do things like show some HTTPS connections as
>> if they were HTTP - e.g. for self-signed certificates, which people just
>> use when they want eavesdropping protection - without our UI being
>> inconsistent.
>
> What happens when there is a host called wibble.example.com, and it runs
> an intranet on http and a webmail service on https, with a self-signed
> cert. The UI would be consistent (indeed, identical), but the content
> would be completely different.

Who actually runs two different websites on the same URL, one http and
one https? Given that it's easy to use DNS to give the machine two names...

(Yes, I know about SSL and the lack of vhosting. That's different.)

> I don't imagine this matters in terms of Paypal, Ebay, as they will have
> everything on different host names. But in smaller settings, there may
> well be 1 host name with a bunch of different services, and they would be
> confusing and spoofable. For example, I could set up some HTML pages on
> an FTP server on a host which was running the organisation's intranet, and
> make it look like I'd replaced the intranet with my web pages.

But surely if you have access to do that, you could just replace the
pages anyway?

> But it could mean for a radically different hostname, you have a similar
> textual name. If someone gets an EV certificate for Manybank Inc, they
> can host their site at https://kjasdffdsfjewf.evil.com and the URL bar
> will be almost identical to the genuine site of Anybank Inc.

If you can get an EV cert for the same or a similar name, getting a
similar domain name would be the easy bit. I'm not sure what extra
protection showing both would actually afford.

>> A flag is safe because we are actually talking about countries,
>> not languages, and it might be more recognisable and differentiable. IE
>> and Opera are using letters.
>
> I guess that would have to be examined, but I think I'd be more easily
> able to recognise and distinguish countries by letters than by a 16-pixel
> or so wide version of a flag. I guess for this purpose I only really need
> to recognise my own country flag and the flag of a country I'm likely to
> be doing a lot of business with, and recognise any other flag as
> "something else".

Indeed.

>> 6) Focus turns bar back to a text box
>>
>> On focus, move back towards being a text box. People have important
>> behaviours to do with URL bar hand-editing that we don't want to break.
>
> How would this fit together with replacing the hostname with the
> certificate name? Would it switch back to showing the hostname when
> focused? Or would we be happy to completely break the stuff you discuss
> here for sites with EV?

Good question. I guess it would switch back.

The whole "don't have things jump around on focus" thing is looking
harder and harder to do...

Gerv

Dao Gottwald

unread,
Feb 16, 2007, 11:17:28 AM2/16/07
to
Robert Kaiser wrote:
> Gervase Markham schrieb:
>> - Make common operations easier
>
> A common operation for me is to edit the domain name and look at the
> same URL on a different domain, as I'm maintaining a bunch of sites
> using the same system and using the same path/querystring parts of their
> URLs on different domains.

The Locationbar² extension for Firefox (as in bug 366797) allows to
select the domain name with a single click.

> That and the difference between HTTP and FTP in some common cases makes
> me think instead of removing the protocol, we should just display it
> differently, e.g. replace "http://" with something that says "Web:" or
> so, "https://" could get "Web (secure):", "ftp://" could be converted to
> "FTP:" or "Remote file:", then "file://" could be "Local file:" - in
> this case, we could even leave favicons in (and use some nice favicons
> for ftp/file), as "[file icon] Local file: /home/robert/" is far enough
> from a spoofed "[file icon] Web: fakehome.com /robert/" or such.

I like the semantics, but it also takes away space. People will complain
and call it clutter.

Dao Gottwald

unread,
Feb 16, 2007, 11:23:46 AM2/16/07
to
Gervase Markham wrote:
> Hmm. It is going to be hard to square the circle of "hide some stuff",
> "allow copying of everything" and "don't make stuff move when you focus
> the URL bar"...

In editable documents, the content of hidden nodes gets copied, if they
are inside of the selection.

Robert Kaiser

unread,
Feb 16, 2007, 11:39:03 AM2/16/07
to
Dao Gottwald schrieb:

> Robert Kaiser wrote:
>> Gervase Markham schrieb:
>>> - Make common operations easier
>>
>> A common operation for me is to edit the domain name and look at the
>> same URL on a different domain, as I'm maintaining a bunch of sites
>> using the same system and using the same path/querystring parts of
>> their URLs on different domains.
>
> The Locationbar² extension for Firefox (as in bug 366797) allows to
> select the domain name with a single click.

Well, I neither use Firefox nor extensions, I merely commented on Gerv's
proposal here, not on any already-done try to improve the location bar
(though I know and see how much hard work you've been putting into one
possible path of improvements).

>> That and the difference between HTTP and FTP in some common cases
>> makes me think instead of removing the protocol, we should just
>> display it differently, e.g. replace "http://" with something that
>> says "Web:" or so, "https://" could get "Web (secure):", "ftp://"
>> could be converted to "FTP:" or "Remote file:", then "file://" could
>> be "Local file:" - in this case, we could even leave favicons in (and
>> use some nice favicons for ftp/file), as "[file icon] Local file:
>> /home/robert/" is far enough from a spoofed "[file icon] Web:
>> fakehome.com /robert/" or such.
>
> I like the semantics, but it also takes away space. People will complain
> and call it clutter.

Those that complain should get a pref to turn back to the simple-URL
display. Every other extension to the location bar could be called
"clutter" in the same way.

Robert Kaiser

Robert Kaiser

unread,
Feb 16, 2007, 11:48:10 AM2/16/07
to
Gervase Markham schrieb:

> I'm not arguing that there is no difference between a machine accessed
> over HTTP and FTP; I'm arguing that a web user doesn't really care which
> one he's using when he clicks a link to go there. The readable vs.
> writable thing doesn't matter for a browser, which doesn't offer FTP
> writing facilities.

Umm, I actually though we did. And btw, why shouldn't we?

Robert Kaiser

Mardak

unread,
Feb 16, 2007, 12:51:53 PM2/16/07
to
On Feb 15, 12:19 pm, Gervase Markham <g...@mozilla.org> wrote:
> - Make the hostname stand out more to reduce spoofing

How extensive should this be to keep the interface consistent?

Examples of other places to recplicate the hostname emphasis.
- History entries in autocomplete dropdown
- Status bar (setting the status bar to be some text would not trigger
the emphasis)
- URL bar (as you type - instant notification if you mistyped)
- Bookmarks

Saurabh Minni

unread,
Feb 16, 2007, 12:51:58 PM2/16/07
to dev-apps...@lists.mozilla.org

Michael Lefevre wrote:

> I don't imagine this matters in terms of Paypal, Ebay, as they will have
> everything on different host names. But in smaller settings, there may
> well be 1 host name with a bunch of different services, and they would be
> confusing and spoofable. For example, I could set up some HTML pages on
> an FTP server on a host which was running the organisation's intranet,
> and
> make it look like I'd replaced the intranet with my web pages.

Why not add a system of Whitelist. Just like blacklist as done currently
by FF. We can make a list of pages for the frequently used sites
online. That would provide best protection. At least in case of better
known sites. The research also shows that its usually the big cos that
are put under the phishing attack generally..

Tony Mechelynck

unread,
Feb 16, 2007, 2:20:36 PM2/16/07
to

I know at least one browser (admittedly not a Mozilla one) which does it:
Konqueror, where I can upload or download multiple files over FTP by drag&drop
from one tab to another (I have done it in either direction between a file:///
URL and an ftp:// URL; I guess it might even work between two ftp:// URLs but
I haven't tested the latter.) (The last time I tried the FireFTP extension, it
was too buggy for everyday use.)

Now I'm not saying that Mozilla should blindly imitate its competitors; but
neither should it blind itself to nice features which the competition might offer.


Best regards,
Tony.
--
Never tell a lie unless it is absolutely convenient.

Tony Mechelynck

unread,
Feb 16, 2007, 2:30:24 PM2/16/07
to
Gervase Markham wrote:
> Mark Finkle wrote:
[...]

>> * I do not believe the button-style is required and I feel it creates
>> too much "noise" in the URL bar.
>
> You feel the bolding is sufficient? The problem with bolding is that it
> doesn't work well for some scripts (e.g. Chinese).
[...]

Bolding, underlining, changing text or background colour... Maybe it would be
enough to define a class or classes for the highlighted text, probably a
default style too, and let themes and/or userChrome.css change it at will.


Best regards,
Tony.
--
"Plaese porrf raed."
-- Prof. Michael O'Longhlin, S.U.N.Y. Purchase

Karl Guertin

unread,
Feb 16, 2007, 2:31:36 PM2/16/07
to
On Feb 16, 10:32 am, Gervase Markham <g...@mozilla.org> wrote:
> > 1. Will every Google service be showing "(flag) Google, Inc"? While
> > good for security, it'd be harder to distinguish the services without
> > knowing the service icon (if the service has one).
>
> Surely you distinguish between Google services by, er, looking at the
> content area? :-)
Reasonable answer. I recognize that most people probably don't look at
the domain/site icon when they're flipping between tabs like I do. I
will say that content area doesn't show up in history/bookmarks/
statusbar/etc. Without seeing the domain in the statusbar, there's
less reinforcement of site identity.

> Copy/pasting should work as now; when you focus the
> URL bar, it turns back to a text box.

I mostly mention the copy and paste due to the edge cases. I'm
assuming you're going to include the scheme in the copied text. Under
which conditions is the scheme added? When the full location is
selected? When the selection includes the full domain (my vote)? When
I have 'mozilla.org' selected and I'm on 'addons.mozilla.org'? I'm not
sure whether removing the scheme would be a net win or a net loss,
just trying to point out possible problems with removing the domain.

I do believe that making the domain a clickable button is a usability
loss. The 'click the mast head, go to site root' is pervasive enough
that a similar feature in chrome is largely redundant. It's the ghost
of <link rel=> nav bar past! I'm also fairly confident -- as confident
as I can be without an actual study -- that it will totally screw up
people trying to correct mistyped domain names. I think a button after
the domain _could_ work, but it still smacks of developer-geekiness
rather than end user desire.

The only other thing I have to say is that I suggest MoFo conduct some
actual usability studies on whatever the changes wind up being, as you
are changing a fundamental piece of the browser's UI. Good luck with
the changes, I'll be checking in on this thread but I'm retired from
arguing about chrome.

Asrail

unread,
Feb 16, 2007, 2:38:56 PM2/16/07
to
Robert Kaiser, 16-02-2007 13:48:

SeaMonkey does this Robert, Firefox doesn't.

Maybe it's too confusing to the ordinary user :P.


Asrail

unread,
Feb 16, 2007, 2:54:24 PM2/16/07
to
Gervase Markham, 16-02-2007 12:55:

> Asrail wrote:
>> I don't think it's really needed by default. A "Micros Soft
>> Cooporation" on Jamaica could confuse someone, anyway.
>
> No more, and hopefully a lot less, than www.micros0ft.com.

OK.

>> I don't think you loose too much setting it to false.
>
> http://wwwnew.towson.edu/ows/lose_lose.htm :-)

Dam my keyboard, please be patient.

>> We could have a icon representing a web-page, another one for a secure
>> web-page, another for remote files, another for local files (maybe one
>> for each protocol or to stick with a default one).
>
> What, where the favicon now is? I'm not sure this icon would add much
> value. Those protocols that don't provide a favicon can have a standard
> icon in the same place (on the tabs), but I don't see much value in an
> icon telling you "this is a web page". And of course we have other UI to
> tell you "this is a secure web page".

What should you have to be able to drag the URL to the bookmarks or some
tab? It was just an idea.

>>> The 3D-ness of the domain button becomes faded and 2-D - so the
>>> separation is still visible, but the URL now looks flat. The URL bar
>>> acts as much like a single text box as possible. The spaces between
>>> different parts remain (to keep the text stable; the text must
>>> absolutely not move on focus, otherwise the caret appears somewhere
>>> different from where you clicked) but if you select and copy, the
>>> spaces don't appear.
>>
>> Please, I wanna my protocol.
>
> Why? Just so you can copy it, or for some other reason also?

Copy and also to be able to change it quickly.
Some places on the web tell you to change "http" for "https", for instance.
Also you could change http for ftp if you do prefer using it to browse
remote directories and the link on the page (and was linked to a http one).

>> I complained about it before testing the extension and I've seen you
>> saw it on mouseover. Is every time worse to get it and your way it's
>> impossible.
>> So we would loose the ability to copy the whole URL, including the
>> protocol.
>
> Hmm. It is going to be hard to square the circle of "hide some stuff",
> "allow copying of everything" and "don't make stuff move when you focus
> the URL bar"...

It may be hard, but I hope we do it.

>>> 7) Change selection behaviour
>>>
>>> People edit individual URL components. So, we should make it easier
>>> to select individual components. Like in a word-processor, a
>>> single-click focusses, a double-click selects a component ("word") -
>>> hostname, path segment, URL parameter key+value or fragment
>>> identifier, and a triple-click selects the entire URL (equivalent to
>>> "select line").
>>
>> How do you select the hostname clicking it while it's a button that
>> will execute some action when clicked :D? (Changing from "clearly a
>> button" to "is it a button?" on mouseover is bad)
>
> Good point.
>
>>> Again, I don't know if this is a can of worms - I suspect URL bar
>>> selection behaviour has been discussed before.
>>
>> And we arrived where?
>> Correct me if wrong, but from your proposal, if I typed
>> aVeryLongLongLongImenseUrl.aGreatDomain.com with a little mistake I
>> would have to type it all over again (and I could make another mistake).
>
> No; once the URL bar is focussed, you can edit the domain name.

it's more natural to click in the place he did the mistake and that
would lead the user to another page, instead of allowing him to edit it.
Why should he click on some white space or another place of the URL when
the typo is in the domain?

>> The user should be able to choose the font he wants.
>> At Linux, for instance, with gtk2, every user expects the gtk2
>> programs to use their gtk2 fonts on the interface, except he stated
>> otherwise.
>> Why should FX to be different?
>
> Because perhaps, for example, the default GTK font produces a security
> risk by not differentiating enough between certain characters? Or
> perhaps it doesn't have glyphs for certain characters?
>

OK. But I would prefer finding another way.


PS: I accept ideas also for changes in the http/https GUI ;)

Tony Mechelynck

unread,
Feb 16, 2007, 2:56:13 PM2/16/07
to
Gervase Markham wrote:
> Asrail wrote:
[...]

>> The user should be able to choose the font he wants.
>> At Linux, for instance, with gtk2, every user expects the gtk2
>> programs to use their gtk2 fonts on the interface, except he stated
>> otherwise.
>> Why should FX to be different?
>
> Because perhaps, for example, the default GTK font produces a security
> risk by not differentiating enough between certain characters? Or
> perhaps it doesn't have glyphs for certain characters?
>
> Gerv

At the moment, every (advanced) user can, if he wants, select the URL bar
font: here is, as an example, an extract from my userChrome.css:

/****************************************************************
* FONTS *
****************************************************************/
/*
* Give the Location (URL) Bar a fixed-width font
*/
#urlbar
{ font-family:
"SUSE Sans Mono",
"B&H LucidaTypewriter",
"Courier New",
Courier,
monospace !important
; font-size: 8pt !important
}

Less advanced users can select default fonts in the Preferences UI; but I'm
not sure whether this set of prefs applies to Content only, or also to Chrome.


Best regards,
Tony.
--
Hug O' War

I will not play at tug o' war.
I'd rather play at hug o' war,
Where everyone hugs
Instead of tugs,
Where everyone giggles
And rolls on the rug,
Where everyone kisses,
And everyone grins,
And everyone cuddles,
And everyone wins.
-- Shel Silverstein

Tony Mechelynck

unread,
Feb 16, 2007, 3:02:20 PM2/16/07
to
Michael Lefevre wrote:
> On 2007-02-15, Gervase Markham <ge...@mozilla.org> wrote:
[...]

>> A flag is safe because we are actually talking about countries,
>> not languages, and it might be more recognisable and differentiable. IE
>> and Opera are using letters.
>
> I guess that would have to be examined, but I think I'd be more easily
> able to recognise and distinguish countries by letters than by a 16-pixel
> or so wide version of a flag. I guess for this purpose I only really need
> to recognise my own country flag and the flag of a country I'm likely to
> be doing a lot of business with, and recognise any other flag as
> "something else".
[...]

The Flags extension displays a flag (or a COM or ORG icon) on the status bar;
IMHO this is enough for whoever wants a flag -- no need to duplicate it in the
URL bar.


Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
38. You wake up at 3 a.m. to go to the bathroom and stop and check your e-mail
on the way back to bed.

Tony Mechelynck

unread,
Feb 16, 2007, 3:23:12 PM2/16/07
to
Gervase Markham wrote:
[...]

> Heikki said:
>> My biggest fear is with replacing the host with business name and
>> country. Most companies own different hosts, in completely different
>> domain names. I think there can be cases where it matters to the user
>> to know which host they are connected to, not just which company.
>
> Can you give an example of where the user would care about which host
> they were connected to, as long as it were one owned by the correct
> company? I know I certainly don't care if my Google search results are
> served by www.l.google.com or www.q.google.com.

It may matter whether they are served by www.google.com or www.google.cn,
because the Chinese Google is censored by the People's Republic. Try googling
for "tienanmen": IIRC, in Google (China) you get a photo of a peaceful square
with a statue of Chairman Mao, while in (let's say) Google (France) you get a
photo of the "Peking Spring" uprising and its repression.

[...]


> J. Ruigrok van der Werven said:

[...]


>> Using bold might be cute for latin-based/derived languages, it
>> totally messes up fonts for Asian languages and possibly others due
>> to strokes becoming thicker and in some cases omitted to preserve the
>> form.
>
> I agree that the method of domain emphasis may have to vary based on
> locale. Which is not ideal. We may just drop the bold entirely, and rely
> on the button surround to pick out the name. How do you do emphasis in
> Kanji? Underlining?
>
> Gerv

I think I've seen Hanzi/Kanji emphasis done by bracketing (using some CJK
brackets, black with a squarish outside and a concave inside) in some CJK spam
I've been getting. Which gets back to the "button" option, but with
"localizable" brackets. Other options are bolding, underlining, or color
(fg/bg) emphasis. IMHO (as I said elsewhere in this thread) any option we
choose should be only a "default", changeable by themes and by userChrome.css
-- which suggests any kind of CSS style should be possible, including e.g.
surrounding with an outline.


Best regards,
Tony.
--
A lot of people I know believe in positive thinking, and so do I. I
believe everything positively stinks.
-- Lew Col

ksu...@volny.cz

unread,
Feb 16, 2007, 3:27:41 PM2/16/07
to
> - Make the contents of the URL bar more understandable

I haven't seen it mentioned yet - please display urlescaped characters
properly. Many languages just don't work with ascii very well... which
is more understandable
http://ja.wikipedia.org/wiki/メインページ
or
http://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8

This only applies to the "file" part of the URL, because the GET query
might well contain non-textual data, and un-escaping it might not
provide reasonable results.

> 1) Hide the scheme

Please keep it. While I understand that selecting the whole URL
(including scheme) will still be possible, you have to realize that
many "normal" users don't really use copy'n'paste, they look at the
adress and type it from memory (and sometimes, you even have to type
the adress on paper). Even today, you get a lot of people posting
broken links with the scheme missing, because somehow they think that
part isn't important. Try explain to your grandmother that if other UI
indicates a difference between http, https or ftp she has to correctly
infer the protocol scheme to write the adress correctly on a post-it
note (or focus the URL bar to turn it back into a textbox).

OK, maybe I'm overreacting a bit - in the majority of cases the scheme
really is irrelevant and doesn't need to be written on post-it notes
by anyone (because it's http, and if it's https you usually get
redirected to the secure version anyway). But if you type a ftp url
without the scheme into the adress bar, you could get into problems
(unless the browser tries the possible variants for you).

> Clicking the hostname "button" takes you back to the root of the site -

> and this would affect which of these two options we actually choose.
> Consider george.blogspot.com/archive/... - do we want to go back to
> george.blogspot.com or blogspot.com?

Actually, most of the time when I click on the domain, I want to
select it copy it to the clipboard (sans the rest of the URL). I'll
have to try the Locationbar extension, it looks cool enough, but I'm
not sure wether I'll like it... But I agree that it would be sometimes
handy if the adress would be "buttonized".

So, how about a hover menu? When you move the mouse over the location
bar, a hover menu fades in where you have buttons for each part of the
adress, while the actual adress is always clickable like a text field
(maybe plus some background coloring to separate the domain name.

Kim

Tony Mechelynck

unread,
Feb 16, 2007, 3:38:18 PM2/16/07
to
Gervase Markham wrote:
> Gervase Markham wrote:
>> 3) Highlight hostname
>>
>> Take either the entire hostname or the Effective TLD + 1 and highlight
>> it in a button-like style. So either:
>
> Several people, both on the blog and here in the newsgroup, have
> mentioned making all the path components clickable buttons, instead of
> just the domain. This is a fairly common suggestion, and I almost
> addressed it in the original post. I'm doing so now, in a new thread part.
>
> I'm wary of such an approach, for the following reasons:
>
> * You don't know if moving up directories will actually produce a
> meaningful page. On good websites it does, but not all websites are
> good. More research may be needed, but adding a load of buttons to the
> interface which take people to a 404 or a 500 probably isn't good UI
> design.

There is already an extension which adds an "up-arrow" button for moving up
one level in the directory tree. And indeed, "not all websites are good": user
sites hosted by my ISP contain anything the owning user decides to upload, and
a "bare" directory URL will produce an error page (ISP-specific) unless that
directory includes at least one of index.htm, index.html, INDEX.HTM and
INDEX.HTML.

>
> * If all the path components are buttoned, then there's nowhere you can
> click to focus the URL bar and turn it into a text box.

between buttons, or in the white space at the left or right ends.

>
> * One reason this works well in e.g. file managers is that they know all
> the possible options for a path component, and can present them in a
> dropdown. We don't in most cases.
>
> Gerv

- There is a dropdown for "complete from history" which is, IIRC, governed by
some pref (about:config only or Prefs-UI I don't recall of the top of my
head). Of course, it gives only all "currently known" completions, not all
"possible" ones.
- For file:/// and ftp:// URLs it is possible to get the directory listing --
indeed, I guess it shouldn't be overly hard to browse directories of these
protocols file-manager-wise.


Best regards,
Tony.
--
A person who has both feet planted firmly in the air can be safely
called a liberal.

Ben Bucksch

unread,
Feb 16, 2007, 3:38:20 PM2/16/07
to
Responding to your proposal. I may also post my own one here again.

Gervase Markham wrote:
> 1) Hide the scheme

Agreed.

> also means we could do things like show some HTTPS connections as if

> they were HTTP ... This is an improvement on the current behaviour,
> which is just to throw an error.

Totally Agreed

> 2) Hide username and password

Agreed.

> 3) Highlight hostname

Totally Agreed.

And always show it, truncate on beginning with "..." when absolutely
necessary.

Important: Domain only, not hostname. Because of...

Also: I like your mockup on the blog with the real button vs. normal
text, the domain is really totally taking over the eye. I think it is
not prominent enough in your mockup of a whole urlbar.

> microsoft.com.foo.bar.baz.evil.com


> For file URLs, you'd get:
>
> [C:] /Program Files/Firefox/
>
> on Windows, and
>
> [/] home/gerv/test/

Agreed.

> 4) Display EV business name and country

Agreed.


>
> For HTTPS connections with EV certificates, replace the hostname with

> the O (Organisation) and C (Country) fields from the certificate. So:
>
> [* Paypal, Inc.] /foo/bar/baz?q=x

Strongly DISagreed.

Reasons:

* The domain is still the main trust root, the realname just
additional trust root.
* Uniqueness on domainnames is more strictly enforced and easier
than real names.
* We may be able to disable IDN (international domain names), but we
can't cowards out of showing international characters in real
names, reopening the whole homograph issue.
* There's a whole new way to have phishing with similar or confusing
names, e.g. eBay Helpers, Inc..
* Many company may have a real name that is not easily recognizable,
making people just accept anything even more than they do now!
Right now, it's easy to protect yourself against phishing, only
the most stupid or novice people fall for it. With real company
names, even I am sometimes not sure whether that company is now
the one I know or some other company.
* There are actually cases where two or more companies have almost
the same name. One of my father's companies is called "P&M
Consulting" <http://www.pm-consulting.com>. Now, look at
<http://www.google.com/search?q=P+M+consulting>.

Using the realname as *only* trust root is a really bad idea, IMHO. As
additional one: great. So, show the realname to the left of the urlbar,
shifting the URLbar to the right. That means the realname will then
appear where the hostname usually is, but the hostname is still there
and just as prominent as button etc.

> 5) Remove the favicon from the URL bar entirely

Agreed.

> This would probably imply making the tab bar always visible ... so
> that the favicon was always visible

Not good enough reason for a whole toolbar. It's just a tiny icon, after
all. The tabbar looks quite ridiculous with only one tab. Do we want to
encourage people to load more tabs, jumping around, not concentrating on
one page? :) (OK, I'm a bit off.)

Also, favicons in tab headers are still in chrome.

I'd suggest to drop this change from the proposal, it's only vaguely
related.

> page-proxy-icon ... that role could be taken over by the domain name
> button, perhaps.

Agreed.

> Perhaps we might consider a fixed-width font in the URL bar?

No!!! I absolutely hate fixed fonts. I think they should remain at
typewriters and mainframes, thank you.

--
When responding via mail, please remove the ".news" from the email address.

Myk Melez

unread,
Feb 16, 2007, 3:45:37 PM2/16/07
to
Gervase Markham wrote:

> I'm not completely sure what to do about the port number. I agree that
> it's theoretically possible that two entirely different entities could
> control port 80 and port 90; but it is certainly unusual.

One option would be to display (and emphasize) the port if isn't the
default port for the given protocol. The port would almost never
appear, and thus it wouldn't be in the way most of the time but might
raise a red flag when it does show up.

-myk

Tony Mechelynck

unread,
Feb 16, 2007, 3:46:27 PM2/16/07
to

IMHO there ought to be a setting somewhere to revert to the current behaviour.
So some people would be able to get the "more meaningful for newbies" display,
while others could get the "tech" display (with http: ftp: etc. at the left)
or even the "uncluttered" display (with no protocol, or only an icon).


Best regards,
Tony.
--
If I don't see you in the future, I'll see you in the pasture.

Asrail

unread,
Feb 16, 2007, 3:50:37 PM2/16/07
to
Gervase Markham, 16-02-2007 12:32:

> J. Ruigrok van der Werven said:
> [snip]

>> Using bold might be cute for latin-based/derived languages, it
>> totally messes up fonts for Asian languages and possibly others due
>> to strokes becoming thicker and in some cases omitted to preserve the
>> form.
>
> I agree that the method of domain emphasis may have to vary based on
> locale. Which is not ideal. We may just drop the bold entirely, and rely
> on the button surround to pick out the name. How do you do emphasis in
> Kanji? Underlining?
>

Just to remember that using the button alone would trigger the full
versus effective domain link issue (the user would like to go to
wiki.mozilla.org or mozilla.org, probably wiki.mozilla.org, but covering
the full domain would cover microsoft.somehacker.com and also some
servers don't listen at the effective domain, ugh).


Ben Bucksch

unread,
Feb 16, 2007, 4:17:03 PM2/16/07
to
Gervase Markham wrote:
> Can you give an example of where the user would care about which host
> they were connected to, as long as it were one owned by the correct
> company? I know I certainly don't care if my Google search results are
> served by www.l.google.com or www.q.google.com.

Oh, Google is a great example! google.de, google.fr and google.com give
totally different results. And not just due to the default language
(which changes basically all results and I don't know why until I see
"google.fr", a clue which would then be gone), but also the
government-induced filters. Not that you enter google.com and end up at
google.fr automatically, redirection based on (bad) IP address location
guessing.

I don't know whether google.de is run by a German company or Google in
USA. The fact that I don't know it means it's arbitrary, and should not
have effect on the UI. And in this case, one company setup would even
break the UI (different results, but same URL display).


Stepping back from that, more generally: If you say I don't care about
the hostname, why do I care about the path then? Why not drop the whole
URL and have a domain only? Surely, the hostname is more significant
than the path. And the second level domain more than the hostname.

> I'm not completely sure what to do about the port number. I agree that
> it's theoretically possible that two entirely different entities could
> control port 80 and port 90; but it is certainly unusual.

Not at all! The whole *point* of serving on different ports is to have
different sites on it. Day-to-day example: SSH port forwarding to an
intranet which gave me SSH, but doesn't have OpenVPN.

The port, if not the default, is just as significant as the hostname.
Treat it in UI similarly (i.e. don't emphasize it, but leave it in).

> [differentiate between www.google.com and groups.google.com]


>
> Surely you distinguish between Google services by, er, looking at the
> content area? :-)

I thought we wanted to move people *away* from using the content area to
identify where they are?

> I agree that the method of domain emphasis may have to vary based on
> locale. Which is not ideal.

Wait. We're talking about domain names only. I thought we dropped IDN?
If not, we can still find other ways to emphasize things for IDNs, or
simply not bold at all in that case. Still, 99.9+% of all domains are
a-z0-9.

Jeff Walden

unread,
Feb 16, 2007, 4:20:42 PM2/16/07
to
Asrail wrote:
> Maybe it's too confusing to the ordinary user :P.

More likely it's not generally useful -- the set of users who need to upload files via FTP is small and is often better served by a real uploading application. Also, exposing FTP uploading in UI will confuse some non-negligible portion of the people who don't need and wouldn't use it.

Jeff

Peter Lairo

unread,
Feb 16, 2007, 4:19:56 PM2/16/07
to
Robert Kaiser wrote:
> Dao Gottwald schrieb:
>>> I think a prefix like
>>> [My Computer] /home/gerv/test
>>> would be horrible, particularly on Unix.
>> Why?
> The root of the file system is just "/" in unix-ish systems, and I don't
> think inventing words for that makes a lot of use.

So how about [root]?
--
Regards,

Peter Lairo

The browser you can trust: www.GetFirefox.com
Reclaim Your Inbox: www.GetThunderbird.com

Saravanan

unread,
Feb 16, 2007, 4:22:40 PM2/16/07
to dev-apps...@lists.mozilla.org
On 16 Feb 2007 12:27:41 -0800, ksu...@volny.cz <ksu...@volny.cz> wrote:
> > - Make the contents of the URL bar more understandable
>
> I haven't seen it mentioned yet - please display urlescaped characters
> properly. Many languages just don't work with ascii very well... which
> is more understandable
> http://ja.wikipedia.org/wiki/メインページ
> or
> http://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8
>
+1 from me.
Opera, Konqueror and IE (to a certain extent) display it URLs with
Unicode characters correctly without escaping. Firefox should follow
the same way.

Thanks
Saravanan

Asrail

unread,
Feb 16, 2007, 4:52:11 PM2/16/07
to
Saravanan, 16-02-2007 18:22:

The locationbar2 extension already does this.
This is one of the main goals (side by side with avoid phishing).

Ben Bucksch

unread,
Feb 16, 2007, 5:04:47 PM2/16/07
to
Gervase Markham wrote:
> My gut tells me that clearing out the URL and replacing it with
> something else would be pretty common

Yes. It wasn't easy to explain my mom how to even enter a URL, because I
had to explain her how to mark text - given that she's new to the
computer, this is hard for her, and holding and moving the mouse right
is not easy in the beginning either.

So, make it very easy to replace the whole URL with a new one. Very
obvious, no additional screen space. It's probably be unrelated to your
proposal, though. (It would be related to mine, though.)

>> (Mark Finkle) I do not believe the button-style is required


> You feel the bolding is sufficient?

No! It is not. Far too subtle. The domain should appear to be something
completely *different* from the rest of the URL. Because it kind of is -
it's the only part interesting to most people. That's one of the roots
of the phishing problem: People ignore the URL, because they see it all
as technical glibberish.

If your proposal ends up in practice as "Bold the domain", the proposal
failed. It won't make much of a difference in practice.

Jason Barnabe (np)

unread,
Feb 16, 2007, 5:10:26 PM2/16/07
to
On Feb 16, 9:08 am, Dao Gottwald <d...@design-noir.de> wrote:
> Robert Kaiser wrote:
> > Maybe because
> > [My Computer] /mnt/srv/software/
> > would be on a server elsewhere and not actually my computer here on my
> > system?
>
> There's nothing wrong with that. The starting point is still your file
> system ("/" alias "my computer").

On Windows XP, servers on UNC paths are not considered a part of "My
Computer"; going "Up" from a UNC path will take your through a network
tree, to "My Network Places", and finally the Desktop, never "My
Computer". Mapped drives, on the other hand *are* displayed as part of
"My Computer".

I don't see any need to force one OS's terminology on the other - on
systems that call the file system "My Computer", we can put "My
Computer", for the file systems that call it "/", we can put "/".

Heikki Toivonen

unread,
Feb 16, 2007, 7:36:55 PM2/16/07
to
Gervase Markham wrote:
> I'm not arguing that there is no difference between a machine accessed
> over HTTP and FTP; I'm arguing that a web user doesn't really care which
> one he's using when he clicks a link to go there. The readable vs.
> writable thing doesn't matter for a browser, which doesn't offer FTP
> writing facilities.

I am repeating my concern stated on your blog, and echoed by another
person about the concern in hiding parts of the URL.

Hiding scheme may make it hard to figure out if you are connected over
SSL or not (especially if the UI changes to not distinguish between
plain HTTP and self signed certs + SSL). And if there is additional
functionality like in the case of ftp it would be nice to know that too.

My concern about hiding the domain was about potential situations where
the same company controls multiple domains. Maybe you can tell the
difference from the content, maybe not (I have tried to search Google
myself several times, without realizing I was on Google News).

However, I think the point that really convinced me that hiding parts of
URLs is bad is that we'd then find bunch of broken links on the web. If
my mom sees the location bar say:

Example Business, Inc. / shopping / basket ? id=1

she would be likely to *type* that in an email to a friend to take a
look at the product, rather than copy and paste. Also, if I were to take
a screenshot of a browser window showing

Example Business Inc. / main.php

and make a bug report saying that web page does not lay out properly in
Firefox, you'd be pretty frustrated...

--
Heikki Toivonen

Heikki Toivonen

unread,
Feb 16, 2007, 7:46:51 PM2/16/07
to
Gervase Markham wrote:
> * If all the path components are buttoned, then there's nowhere you can
> click to focus the URL bar and turn it into a text box.

It can work, but is not as good usability wise, especially with long
urls: you click past the end of the last character in the URL.

But yes, I buy your argument. The most important piece IMO is
highlighting the host.

--
Heikki Toivonen

Saravanan

unread,
Feb 16, 2007, 9:34:25 PM2/16/07
to dev-apps...@lists.mozilla.org

I *knew* that. Locationbar2 extension correctly displays URL with
Unicode characters but it does not allow you to copy those URLs
without escaping.

Thanks
Saravanan

Ben Bucksch

unread,
Feb 16, 2007, 11:39:01 PM2/16/07
to
Heikki Toivonen wrote:
> Hiding scheme may make it hard to figure out if you are connected over
> SSL or not (especially if the UI changes to not distinguish between
> plain HTTP and self signed certs + SSL).

That is the *intent*. We want to allow people to connect to self-signed
HTTPS sites, without warning dialogs, and let them make use of the tiny
bit of extra protection (no passive sniffing), but we *don't* want them
to think it's "secure" or "protected against sniffing and alteration",
because it's not (MITM). If they see SSL / HTTPS, they'll think it is
protected. Hiding the scheme has the *advantage*, not downside, to hide
the fact that it's SSL. We'll show other indicators to show whether it's
protected against sniffing or not.

This really is a critical part in significantly improving our SSL
handling and UI.

Justin Dolske

unread,
Feb 17, 2007, 1:09:29 AM2/17/07
to
Gervase Markham wrote:

> Several people, both on the blog and here in the newsgroup, have
> mentioned making all the path components clickable buttons, instead of
> just the domain. This is a fairly common suggestion, and I almost
> addressed it in the original post. I'm doing so now, in a new thread part.
>
> I'm wary of such an approach, for the following reasons:

I completely agree.

In addition, I think it's safe to assume that most users don't navigate
within a site by editing the URL bar. [Although entering an entirely new
location wouldn't seem unusual.] As such, I'm not sure it's a feature we
really want.

Locationbar^2 did a really great job with implementing most of the
features in the list. The idea of displaying one format when not
focused, but reverting to an editable text field when focused, is key.
Unfortunately the most recent version (which does this clickable-path
thing) is a very disappointing step backwards. Since the URL bar has
traditionally been a text field, I think doing anything to that alters
text field semantics (when focused) isn't going to go over well with users.

This would also imply that the non-focused state shouldn't be too
radically different (to retain discoverability), although the limits are
indistinct. It's worth noting that a "perfect" design for the URL bar
might need a halfway-compromise for Firefox 3, so that users can start
to adjust to the changes.

Justin

Dao Gottwald

unread,
Feb 17, 2007, 4:55:25 AM2/17/07
to
Gervase Markham wrote:
> Several people, both on the blog and here in the newsgroup, have
> mentioned making all the path components clickable buttons, instead of
> just the domain. This is a fairly common suggestion, and I almost
> addressed it in the original post. I'm doing so now, in a new thread part.
>
> I'm wary of such an approach, for the following reasons:
>
> * You don't know if moving up directories will actually produce a
> meaningful page. On good websites it does, but not all websites are
> good. More research may be needed, but adding a load of buttons to the
> interface which take people to a 404 or a 500 probably isn't good UI
> design.
>
> * If all the path components are buttoned, then there's nowhere you can
> click to focus the URL bar and turn it into a text box.
>
> * One reason this works well in e.g. file managers is that they know all
> the possible options for a path component, and can present them in a
> dropdown. We don't in most cases.

I'm going to remove buttons for path segments in the next Lb² release,
but turn the segments into links when the user presses Alt/Option.

Ben Bucksch

unread,
Feb 17, 2007, 9:07:18 AM2/17/07
to
Robert Kaiser wrote:
> Gervase Markham schrieb:
>> I'm not arguing that there is no difference between a machine
>> accessed over HTTP and FTP; I'm arguing that a web user doesn't
>> really care which one he's using when he clicks a link to go there.
>> The readable vs. writable thing doesn't matter for a browser, which
>> doesn't offer FTP writing facilities.
>
> Umm, I actually though we did. And btw, why shouldn't we?

You can also write to HTTP (HTTP PUT etc.). We support both in necko
(network library).

jonq...@gmail.com

unread,
Feb 17, 2007, 2:25:59 PM2/17/07