Location Bar Proposal 1.2

[Sorry - 1.1 was not updated in several important places.
Here's another 
attempt. No further big changes, just made the text
consistent.]

Some excellent arguments in the previous thread have changed
my mind on 
certain issues. So I'm posting a revised proposal here. I
thought a new 
thread rather than a continuation would be better, so it's
clear which 
proposal people are addressing.

The changes do, of course, raise some further questions. And
none of 
them are set in stone - feel free to try and persuade me
back again if 
you think they aren't improvements 

Big changes:

A) Clicking the hostname no longer takes you to the root of
the site. I 
agree, this should remain an in-page navigation option. Lots
of sites 
provide it already, so it's not all that useful. This means
that 
clicking it allows editing, just as with the rest of the
URL, which is 
consistent. Also, removing it allows us to do:

B) URL bar changes to a text box on hover as well as on
focus. (We 
couldn't do this before, as otherwise the hostname button
would be 
unclickable.) This makes it much easier to click where you
want to to 
select part of the URL, because you are clicking where the
caret will 
actually end up, rather than clicking in one place, the form
of the bar 
changing on focus, and the caret actually appearing in
another place 
(albeit between the same, clicked letters).

We could even make it so that the URL bar changes mode when
the mouse 
was over any part of the chrome, not just the URL bar
itself. That means 
that if you moved the mouse from the content towards the URL
bar, it 
would have changed by the time you arrived, and you could
aim at the 
right spot. The exact algorithm would require some careful
tuning. 
Perhaps it could fade quickly between the two forms so as
not to be too 
visually jarring.

This means we can also say:

C) It's not so important that things don't shift around when
the URL bar 
changes modes - because the shift now happens on hover (even
just 
getting close), rather than on focus, so you can move the
mouse, see the 
shift, and then click where you want the caret to be and
it'll stay there.

This means that:

D) We can show the scheme in the text version, without
worrying about 
the jumping around. This removes some concerns people had
about hiding 
the scheme totally. (It's still hidden in the non-text
version.)

Removing "click the hostname" also means that:

E) We highlight Effective TLD + 1, not the entire hostname.
There's no 
need to highlight the entire hostname because "it might
be where people 
want to go when they click" - that rationale is
removed. Sticking with 
Effective TLD + 1 removes the spoofing possibilities of
highlighting all 
of microsoft.com.foo.bar.evil.com.

F) I have changed to Ben and Rimas's suggestion of
_prepending_ the EV 
information to the domain name. IE has it on the far right,
but I think 
prepending it works well, because it's then in the position
the domain 
name used to be, and yet the domain name is still visible
(and 
highlighted). But I'd particularly like further discussion
on this, 
because it raises its own issues.

Location Bar Proposal 1.1
-------------------------

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 when URL bar not focussed/hovered.

The scheme (e.g. "http://", "ftp://")
should be hidden 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.

2) Hide username and password

If present. This is the "foo:bar" in http://foo:barhostname.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.

3) Highlight hostname

Take the Effective TLD + 1 and highlight it (in some way to
be decided). 
So either:

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.

4) 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:

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

6) 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.

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").

For reference, the current behaviour is:

With layout.word_select.stop_at_punctuation=false (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 layout.word_select.stop_at_punctuation=true (default on
Windows):

Single-click places caret
Double-click selects out to punctuation
Triple-click selects everything

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

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
_______________________________________________
dev-apps-firefox mailing list
dev-apps-firefoxlists.mozilla.org
h
ttps://lists.mozilla.org/listinfo/dev-apps-firefox

Asrail wrote:
> There is here a concern about decoding URLs at this
stage.
> If I read:
> http://pt.wikipedia.or
g/wiki/Açcão
> and want to change to:
> http://pt.wikipedia.o
rg/wiki/Acção
> 
> That's fairly easy.
> But if I see:
> http://p
t.wikipedia.org/wiki/A%C3%A7c%C3%A3o
> and wanna change to:
> http://p
t.wikipedia.org/wiki/Ac%C3%A7%C3%A3o
> 
> That's harder. For Japanese and other ruby ones, that's
even harder.
> The user couldn't see anymore the exact place of the
mistake (or another
> thing he wanted to change).
> Our URL bar threats this:
> <http://pt.wikipedia.or
g/wiki/Ação (física)> correctly, so the user
> could see the decoded URL while editing.
> Copying with the spaces would break it almost
everywhere, so FX could
> encode them.

One more thing about it. Though not sure if the devs should
take it
into account or not. In previous thread you mentioned a
Japanese link.
  Windows users may have problems with links like that,
because
Windows often includes only support for typography of
relevant
regions/languages by default, and doesn't add support for
other
regions. For example, I don't think I could actually see
CJK
hieroglyphs on my Windows machine.

Not sure if it's a concern though, as if your computer
doesn't support
those symbols, you should have no need to visit pages that
have them
even in URL... But well...

RQ
_______________________________________________
dev-apps-firefox mailing list
dev-apps-firefoxlists.mozilla.org
h
ttps://lists.mozilla.org/listinfo/dev-apps-firefox

Gervase Markham, 19-02-2007 11:58:
> A) Clicking the hostname no longer takes you to the
root of the site. I 
> agree, this should remain an in-page navigation option.
[...]

I Strongly agreed here. Some places (as <http://people.mozilla.c
om>) 
don't have a useful top level domain page.

> B) URL bar changes to a text box on hover as well as on
focus. (We 
> couldn't do this before, as otherwise the hostname
button would be 
> unclickable.) [...]

Selecting a piece of text without the need to another click
is good.
I was thinking we could have a in-between plain view and
pretty view here.

There is here a concern about decoding URLs at this stage.
If I read:
http://pt.wikipedia.or
g/wiki/Açcão
and want to change to:
http://pt.wikipedia.o
rg/wiki/Acção

That's fairly easy.
But if I see:
http://p
t.wikipedia.org/wiki/A%C3%A7c%C3%A3o
and wanna change to:
http://p
t.wikipedia.org/wiki/Ac%C3%A7%C3%A3o

That's harder. For Japanese and other ruby ones, that's even
harder.
The user couldn't see anymore the exact place of the mistake
(or another 
thing he wanted to change).
Our URL bar threats this:
<http://pt.wikipedia.or
g/wiki/Ação (física)> correctly, so the user 
could see the decoded URL while editing.
Copying with the spaces would break it almost everywhere, so
FX could 
encode them.

That would be a huge benefit for non speakers of a lot of
languages around.

> We could even make it so that the URL bar changes mode
when the mouse 
> was over any part of the chrome, not just the URL bar
itself. That means 
> that if you moved the mouse from the content towards
the URL bar, it 
> would have changed by the time you arrived, and you
could aim at the 
> right spot. The exact algorithm would require some
careful tuning. 

What about the mouse arriving there by change? Because of
switching windows?
This could lead to having a plain view when the user didn't
want and 
that could be confusing.

> [...]
> C) It's not so important that things don't shift around
when the URL bar 
> changes modes - because the shift now happens on hover
(even just 
> getting close), rather than on focus, so you can move
the mouse, see the 
> shift, and then click where you want the caret to be
and it'll stay there.

When you point to something and it moves, that's annoying.
But that's 
better than the old proposal.

> This means that:
> 
> D) We can show the scheme in the text version, without
worrying about 
> the jumping around. This removes some concerns people
had about hiding 
> the scheme totally. (It's still hidden in the non-text
version.)

I believe everyone is happy here, but that could be further
studied (see 
above).

> Removing "click the hostname" also means
that:
> 
> E) We highlight Effective TLD + 1, not the entire
hostname. There's no 
> need to highlight the entire hostname because "it
might be where people 
> want to go when they click" - that rationale is
removed. Sticking with 
> Effective TLD + 1 removes the spoofing possibilities of
highlighting all 
> of microsoft.com.foo.bar.evil.com.

It's a must. No other idea should change this proposal,
IMHO.

> F) I have changed to Ben and Rimas's suggestion of
_prepending_ the EV 
> information to the domain name. IE has it on the far
right, but I think 
> prepending it works well, because it's then in the
position the domain 
> name used to be, and yet the domain name is still
visible (and 
> highlighted). But I'd particularly like further
discussion on this, 
> because it raises its own issues.

The same clue as above about "don't move too much the
things away".
_______________________________________________
dev-apps-firefox mailing list
dev-apps-firefoxlists.mozilla.org
h
ttps://lists.mozilla.org/listinfo/dev-apps-firefox

Kim Sullivan wrote:
>> One more thing about it. Though not sure if the
devs should take it
>> into account or not. In previous thread you
mentioned a Japanese link.
>>   Windows users may have problems with links like
that, because
>> Windows often includes only support for typography
of relevant
>> regions/languages by default, and doesn't add
support for other
>> regions. For example, I don't think I could
actually see CJK
>> hieroglyphs on my Windows machine.
>>
>> Not sure if it's a concern though, as if your
computer doesn't support
>> those symbols, you should have no need to visit
pages that have them
>> even in URL... But well...
> 
> It was me who posted the link to the japanese
wikipedia, and I have a
> plain XP Pro version of windows (it is even possible to
enable
> japanese keyboard input, a lot of people learning e.g.
Japanese do
> this). Even notepad in windows XP works in UTF-8 by
default. The only
> problem might be japanese fonts (because I'm not sure I
didn't install
> those manually... but they should be avaliable on the
install CD). Is
> it possible for FF to detect wether a particular glyph
can be
> displayed, and if not, revert to the url-encoded
version of the whole
> address?

That would be a pretty good solution, if possible...

> (just out of curiosity, can you see the characters in
> http://ja.wikipedia.org
/wiki/メインページ ?)

Yes, but I'm on Linux now. 


I don't mean to sound like an IE lover, but again, I like
the way IE7
handles IDN, and I think we could expand this for anything
concerning
the URL. And what they do is explained in [1].

RQ

[1] http://blogs.msdn.com/ie/archive/2006/07/31/684337.aspx

_______________________________________________
dev-apps-firefox mailing list
dev-apps-firefoxlists.mozilla.org
h
ttps://lists.mozilla.org/listinfo/dev-apps-firefox

On Feb 19, 7:29 pm, Asrail <asr...gmail.com> wrote:
> Our URL bar threats this:
> <http://pt.wikipedia.or
g/wiki/Ação (física)> correctly, so the user
> could see the decoded URL while editing.

I'm sorry, are you talking about LocationBar^2, or maybe the
one in
SM? The version of LocationBar^2 I'm using switches to the
encoded url
for editing (which is a bit annoying).

Kim

_______________________________________________
dev-apps-firefox mailing list
dev-apps-firefoxlists.mozilla.org
h
ttps://lists.mozilla.org/listinfo/dev-apps-firefox

Asrail wrote:
> Kim Sullivan, 19-02-2007 20:34:
>> On Feb 19, 7:29 pm, Asrail <asr...gmail.com> wrote:
>>> Our URL bar threats this:
>>> <http://pt.wikipedia.or
g/wiki/Ação (física)> correctly, so the user
>>> could see the decoded URL while editing.
>>
>> I'm sorry, are you talking about LocationBar^2, or
maybe the one in
>> SM? The version of LocationBar^2 I'm using switches
to the encoded url
>> for editing (which is a bit annoying).
>>
> 
> I'm talking the Gerv's proposal.
> I already have tested every URL bar version available
since version 0.5.
> Not only the ones available at addons.mozilla.org.
> As of version 0.8 it don't decode the URLs.

Sure it does.
_______________________________________________
dev-apps-firefox mailing list
dev-apps-firefoxlists.mozilla.org
h
ttps://lists.mozilla.org/listinfo/dev-apps-firefox

> ONE MORE THING ABOUT IT. THOUGH NOT SURE IF THE DEVS
SHOULD TAKE IT
> INTO ACCOUNT OR NOT. IN PREVIOUS THREAD YOU MENTIONED A
JAPANESE LINK.
>   WINDOWS USERS MAY HAVE PROBLEMS WITH LINKS LIKE THAT,
BECAUSE
> WINDOWS OFTEN INCLUDES ONLY SUPPORT FOR TYPOGRAPHY OF
RELEVANT
> REGIONS/LANGUAGES BY DEFAULT, AND DOESN'T ADD SUPPORT
FOR OTHER
> REGIONS. FOR EXAMPLE, I DON'T THINK I COULD ACTUALLY
SEE CJK
> HIEROGLYPHS ON MY WINDOWS MACHINE.
>
> NOT SURE IF IT'S A CONCERN THOUGH, AS IF YOUR COMPUTER
DOESN'T SUPPORT
> THOSE SYMBOLS, YOU SHOULD HAVE NO NEED TO VISIT PAGES
THAT HAVE THEM
> EVEN IN URL... BUT WELL...

IT WAS ME WHO POSTED THE LINK TO THE JAPANESE WIKIPEDIA, AND
I HAVE A
PLAIN XP PRO VERSION OF WINDOWS (IT IS EVEN POSSIBLE TO
ENABLE
JAPANESE KEYBOARD INPUT, A LOT OF PEOPLE LEARNING E.G.
JAPANESE DO
THIS). EVEN NOTEPAD IN WINDOWS XP WORKS IN UTF-8 BY DEFAULT.
THE ONLY
PROBLEM MIGHT BE JAPANESE FONTS (BECAUSE I'M NOT SURE I
DIDN'T INSTALL
THOSE MANUALLY... BUT THEY SHOULD BE AVALIABLE ON THE
INSTALL CD). IS
IT POSSIBLE FOR FF TO DETECT WETHER A PARTICULAR GLYPH CAN
BE
DISPLAYED, AND IF NOT, REVERT TO THE URL-ENCODED VERSION OF
THE WHOLE
ADDRESS?

(JUST OUT OF CURIOSITY, CAN YOU SEE THE CHARACTERS IN
HTTP://JA.WIKIPEDIA.ORG/WIKI/á¤óÚü¸ ?)

_______________________________________________
DEV-APPS-FIREFOX MAILING LIST
DEV-APPS-FIREFOXLISTS.MOZILLA.ORG
HTTPS://LISTS.MOZILLA.ORG/LISTINFO/DEV-APPS-FIREFOX

Gervase Markham wrote:
> 4) 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.

hehe, take a look at a screenshot here:
http://blogs.msdn.com/ie/ar
chive/2006/10/20/ie7-and-high-assurance-at-rsa-europe.aspx

RQ
_______________________________________________
dev-apps-firefox mailing list
dev-apps-firefoxlists.mozilla.org
h
ttps://lists.mozilla.org/listinfo/dev-apps-firefox

I'd like to summarize the previous discussions about
decoding
characters in paths... I hope I don't omit anything:

To increase readability of URLs, the path part of the URL
should be
displayed as characters, not as an url-encoded string (the
query part
should remain url-encoded, because it is not sure it doesn't
contain
binary data). The status bar should match the display of the
location
bar (currently, it displays all characters decoded, even
whitespace).

Some issues that come to mind (or have been mentioned in
previous
discussions):
- Whitespace handling. Whitespace characters should probably
not be
decoded (this might allow URLs to overflow the visible area
without
indication that this happened). They can either left encoded
(e.g. %20
for a space), or they could be displayed similarly to
"show
whitespace" mode in text editors and word processors
(e.g. using
something like a middle dot for spaces). The first approach
is
probably much easier to implement and a reasonable
compromise between
readable urls and safety.

- How to display the anchor/fragment part of the URL?

- Missing fonts: What happens when an URL contains
characters that
don't have a glyph installed on the system? Can Firefox
detect a
missing glyph, and fall-back to the all-encoded version, or
is it OK
to display a "missing glyph" (on some systems, its
?, on others an
empty rectangle)

- Editing/selection behavior: should the content of the
location bar
change to the encoded version on location bar hover/select?
(this
would be very hard to do seamlessly) This ties in closely
with the
next issue:

- copy/paste behavior: Should the encoded or decoded URL be
copied and
pasted? Is it possible to say "the contents of the
clipboard are a
hyperlink, the destination is this encoded url, and the name
is this
decoded url"? What if only a part of the URL is
selected?
My personal opinion on these two: try to use the decoded
version as
much as possible, both for editing and for cutting and
pasting. FF, IE
and Opera seem to cope well with html pages that contain
non-ascii
characters in hyperlinks, and the w3c validator says it's
valid (I
assume that all browsers are smart enough to encode the URL
anyway for
the http protocol). Switching between the encoded and
decoded version
is a bit annoying (try the current 0.7.2.1 version of the
LocationBar2
extension to see what I mean), and it prevents editing of
the URL (as
mentioned by Asrail).

- Which character set/encoding? I'm not sure if this really
is an
issue (and only applies when decoded URLs will be used for
copying and
pasting anyway). What happens if you copy an URL that's
UTF-8 to a
page that is written in ISO-8859-1 - should FF convert the
characters
to the target character encoding, or paste them byte-by-byte
(no
transformation)? Firefox defaults to UTF-8 (this can be a
problem when
using keyword searches on search engines that default to a
different
encoding, and probably affects URLs typed directly too).

Kim

_______________________________________________
dev-apps-firefox mailing list
dev-apps-firefoxlists.mozilla.org
h
ttps://lists.mozilla.org/listinfo/dev-apps-firefox

Kim Sullivan, 19-02-2007 20:34:
> On Feb 19, 7:29 pm, Asrail <asr...gmail.com> wrote:
>> Our URL bar threats this:
>> <http://pt.wikipedia.or
g/wiki/Ação (física)> correctly, so the user
>> could see the decoded URL while editing.
> 
> I'm sorry, are you talking about LocationBar^2, or
maybe the one in
> SM? The version of LocationBar^2 I'm using switches to
the encoded url
> for editing (which is a bit annoying).
> 

I'm talking the Gerv's proposal.
I already have tested every URL bar version available since
version 0.5.
Not only the ones available at addons.mozilla.org.
As of version 0.8 it don't decode the URLs. As of 0.8.2
spaces are 
re-encoded (I've seen this one right after sending the mail
above).

But the comments here are about the Gerv's proposal, please,
that 
extension is just to play with the proposals.

I meant: the last one LocationBar2 doing something does not
mean anything.


_______________________________________________
dev-apps-firefox mailing list
dev-apps-firefoxlists.mozilla.org
h
ttps://lists.mozilla.org/listinfo/dev-apps-firefox