View source for Firefox3/Location Bar

<i>Version 1.3</i>

Note: this is not a committed Firefox 3 feature.

==Goals==

* Reduce spoofing risks
* Make the Location bar more understandable
* Make common* operations easier
* Don't break stuff people use*

And, optionally:

* Find a way of presenting information from EV certificates

<nowiki>*</nowiki> to be defined by whatever usability data we have

==Suggested Changes==

The grand plan is that the URL bar displays/highlights/picks out/suppresses URL information in a particular (hopefully more useful) way during normal browsing, but returns to acting like a text box on hover or focus.

===Hide the scheme when URL bar not focussed/hovered===

The schemes "http://", "https://", "ftp://" and "file://" should be hidden when the URL bar is not focussed. 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 for such certificates, which is just to throw an error.

===Hide username and password===

This is the "foo:bar" in http://foo:bar@hostname.com. 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.

===Highlight hostname===

Take the [[Gecko:Effective_TLD_Service|Effective TLD]] +1 (or +2 - to be decided) and highlight it in some way to be decided, which may have to be locale-dependent. So:

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

where capital letters indicate some sort of styling such as bold, underline, italic, colour or border. (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 either side of the highlighted text.

For file:// URLs, you'd have no highlighting, as there's no domain.

If the port is non-standard, it is also included in the highlighted part, separated as normal by a colon.

===Display EV business name and country===

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

[* Paypal, Inc.] - www. PAYPAL.COM /foo/bar/baz?q=x

We replace the hostname in geographical space, while still making it visible further to the right. This 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.

We now have two things highlighted; we'd need to do UI experiments to see if that was confusing, and whether we should highlight them the same or different, or whether we should drop the highlighting of the domain name, or something else. The name and flag need to appear non-editable.

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:

===Remove the favicon from the URL bar entirely===

Favicons in the URL bar are dangerous, because they represent the website having some control over what's in the chrome. This danger 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. We would keep the favicon on tabs, of course.

This could lead to 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. Perhaps this issue needs to be separated out.

I believe that the only function of the page-proxy-icon (where the favicon appears) is to be draggable to create e.g. bookmarks toolbar entries. We'd need to replace that function somehow. To be decided.

===Focus/hover turns bar back to a text box===

On focus/hover, 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, or pressing Ctrl-L or equivalent, focusses the URL bar and makes the following changes.

If the domain name is styled in such a way that it looks "uneditable", then the style changes to remove that impression. We should try and keep enough style to make sure the domain is still picked out, if possible. Any hidden information, such as the scheme, returns. The EV business name and country identifier remain (as they aren't editable, so there's no need to do anything to them). The URL bar acts as much like a single text box as possible. This will lead to things shifting about; we'd need to do tests to see if this was too jarring. I hope that the fact that it changes on hover means that it isn't.

URLs may be partly or fully decoded in the unfocussed state, but will be returned to their %-encoded (true) form in the focussed state. (The exact way this works remains to be decided; there are lots of complex interplays. And it's only partly related to this proposal - we have the same problems about how to best show and edit international URLs in the current location bar.)

===Change selection behaviour===

People edit individual URL components. So, we should make it easier to select individual components. Like in a word-processor, I suggest the following behaviour:

* Single-click places caret
* Double-click selects a component ("word") - hostname, path segment, URL parameter key+value or fragment identifier, 
* Triple-click selects the entire URL (equivalent to "select line").

For reference, the current behaviour is:

With <tt>layout.word_select.stop_at_punctuation=false</tt> (default on Linux):

* Single-click places caret
* Double-click selects everything
* Triple-click also selects everything

In other words, the selection never takes account of the different parts of the URL.

With <tt>layout.word_select.stop_at_punctuation=true</tt> (default on Windows):

* Single-click places caret (that's not true, on windows another pref makes single click select the whole contents of the URL bar by default --[[User:Asqueella|Nickolay]])
* Double-click selects out to punctuation
* Triple-click selects everything

URL bar selection behaviour has been [https://bugzilla.mozilla.org/show_bug.cgi?id=190615 discussed before], in a bug which requests that layout.word_select.stop_at_punctuation be set to true on all platforms.

===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.

==Open Issues==

* Do we have any data on how people actually use the URL bar? The above is based on best guesses
* Is username/password hiding turned on already?

The following can probably only be resolved by testing an implementation:

* Do we highlight Effective TLD + 1 or + 2?
* What type of highlighting works best? Does it have to be locale-dependent?
* Is it possible to give Firefox sensible hints about the font to pick?
* Does the suggested EV presentation inform rather than confuse?
* Should we use flags or country codes?
* Do we make the tab bar always visible?
* How do we replace the page-proxy-icon function?
** The selected address can be dragged as well. That's not very discoverable though.
* What do we do about decoding/encoding URLs in the unfocussed state?

==Testing==

[http://en.design-noir.de/mozilla/locationbar2/ Locationbar<sup>2</sup>] implements many of these ideas. This how you configure it to be closest to this proposal:

0.8.5.4: Hide protocols "ftp http https file", and have everything else <b>un</b>checked except blend URLs, blue domains, never show favicon, placeholder for hidden protocols, margin after the host. This isn't perfect; this version has some features not in this proposal.

0.8.6: Hide protocols "ftp http https file", and have everything else <b>un</b>checked except blend URLs, blue domains, "only linkify when...", never show favicon, placeholder for hidden protocols, margin after the host. This is fairly close to the proposal.