Location Bar Proposal
Gervase Markham
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
> 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
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
[...]
> - 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
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
>
> 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
> 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
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
>> 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
[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
> 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
> 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
> 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
> 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
> - 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
> * 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
> 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
>> 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
> 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
>> 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
> 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
> 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
> 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
> 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
> 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
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
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
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
> 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
> > 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? :-)
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
SeaMonkey does this Robert, Firefox doesn't.
Maybe it's too confusing to the ordinary user :P.
Asrail
> 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
> 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
>> 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
[...]
> 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
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
> 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
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
> 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
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
> 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?
>
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
> 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
> 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
> 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
> > - 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
>
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
The locationbar2 extension already does this.
This is one of the main goals (side by side with avoid phishing).
Ben Bucksch
> 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)
> 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
> 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
> * 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
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
> 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
> 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
> 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:
>
> 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.
>
> click to focus the URL bar and turn it into a text box.
>
> 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
> Gervase Markham schrieb:
>> 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.
>
You can also write to HTTP (HTTP PUT etc.). We support both in necko
(network library).
jonq...@gmail.com
> > * 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).
We could use colour, in fact we could make it blue and underlined like
a link.
(each directory in the URL could also be a link, styled similarly that
leads to that directory).
Jon
Michael Lefevre
> Gervase Markham wrote:
[snip]
>> 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,
Although with domains in different countries, you would imagine they would
have EV certs in the appropriate country. Yahoo may be a better example,
where uk.yahoo.com and www.yahoo.com are also different sites, and giving
different search results.
--
Michael
Rimas Kudelis
>>> 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 do, actually. Exactly the way Michael described (https for webmail
and admin tasks, http for main webpage). And I'm sure I'm not the only
one.
However, the users type www.mail.host.tld, and are redirected to
https://host.tld. Still, I'm against many of the changed described here.
RQ
Rimas Kudelis
Gervase Markham wrote:
> 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://.
Please, don't. You could aswell indicate those not-so-trustworthy
HTTPS connections using the "other UI" you mentioned. Also, see below.
> 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.
Hmm, I'm not sure I completely understood this point. Do you want to
apply some stripping to GET urls? Nah, I don't think we want it.
Firstly, because it's unforgivably stupid to transmit user and
password using GET's, and no serious sites should be doing that.
Secondly, you may never know, which get variable holds the username
and password, so you'll never be 100% sure you stripped the right
variables from display.
However, I'm not against stripping the "username:password@" part from
the URLs.
> 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.
I think bold is enough, and the font should remain as chosen by the
user. See below for more.
> 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.
Right. That's difficult. It could just be anything...
A kind of related issue is that Mozilla apps still ignore <link
rel="next"> and similar head items. Adding some buttons (maybe a
separate optional toolbar or something) could solve this issue (not
from anti-phishing point of view, though). Also, see below.
> 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
Solution: you could use:
[C:/] Program Files/Firefox/
to solve the slash problem.
> 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.
Now, here's the "below" part. Have you seen IE7? It adds a small
clickable field with a lock for secure sites. Now we could have
something similar. Why not PREPEND an EV (WTF is EV?) information
instead of replacing the domain name with it? So, it could look like this:
[[L] Paypal, Inc., *] https://www.paypal.com/foo/bar/baz?q=x
The [L] could be replaced by a Lock icon, and a * - with country
letters (US, UK). This whole field could itself be a button, which,
when clicked, could show a dialog with more information, or whatever
you want. This way, you:
1) Don't break stuff people use;
2) Reduce the risk of spoofing (you may still make the hostname
bolded, if you like);
3) Make the common operations easier.
One your goal that isn't met is "Make the contents of the URL bar more
understandable", but I'm not sure we really need it. I certainly don't
want breadcrumbs navigation (for all the reasons stated in those posts
I've read already), and I don't want any blue/green/whatever arrows
either. I want slashes, I want clickable text to edit, and I don't
want it to change on hover or on my click. Really.
> 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.
I agree with this one.
> 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.
You don't need a favicon to do that. I liked the proposal to display
different icon for different protocols here (The lock being an icon
for https sites). So the user could use that protocol-specific icon to
create a bookmark, IMO.
> 6) Focus turns bar back to a text box
See above.
> 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").
I agree. However, I also believe that most people don't really change
the URL often. Instead, they often rewrite it completely, or erase
everything that is after the domain part.
> 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.
It hurts my eyes when some übercool application decides for me what
fonts/colors/button styles etc I want to use in that application, I'm
almost always against that. Well, there always are exceptions, for
example, I like the way how address bar changes its color in Firefox,
depending on SSL state.
However, for example, in Linux, you're simply never sure what fonts
are available and if they are the best choice. Using monospace font
could be a solution, however, still it's a customization and a
departure from what the user has chosen in his global UI prefs (or
what the OS vendor has chosen for the user).
Maybe, instead of a button and bold, we could have some other visual
differentiation? For example, add some border+background for the
domain name part, but not make it a button? And if this weren't a
button, it would be themable through CSS, so it would be fairly easy
to make it different for people with vision problems.
RQ
Rimas Kudelis
> Now, here's the "below" part. Have you seen IE7? It adds a small
> clickable field with a lock for secure sites.
Just for the reference, here's how IE7 handles a website with a
self-signed certificate:
http://pics.rq.online.lt/index.php?folder=/screens/windows/ie7/
Those screenshots also depict how to install a SSL certificate into
IE. You may ignore that part. :)
RQ
Rimas Kudelis
> - 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.
For file://, yes; for ftp:// not necessarily, as I may enter or click
on a URL pointing right to
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/, so Fx won't know
what's in /pub/mozilla.org/
And as file:// remains probably the only URL type where this would
work, I think it's a little inconvenient. Instead, for file:// URL's
Firefox could display more suggestions than history actually contains. ;)
RQ
Rimas Kudelis
>> - 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
Now consider a URL with 30 %20's. If unescaped, these would be
displayed as spaces. And as the URL bar only has finite length (say,
40 symbols, and then text flows out), and no scrollbar, you'll simply
NOT know that the URL you see is incomplete. That's a good phishing
opportunity, IMO. Don't you think so?
This should be thought of before unescaping characters. BTW, how does
Firefox handle IDN currently?
RQ
Asrail
It's "possible" to do the same for FTP.
When you're viewing an FTP connection you share the same connection and
can do multiple requests.
The XUL way of viewing directory listing allow you to do multiple
requests without loading a new page.
It means that an FTP request could be fired when clicking there and the
remote content could be displayed.
It could even be prefetched, so the user would see the list immediately
right after the click.
Well... I'm not saying that I like it, I'm just saying it is possible.
Asrail
>
> Gervase Markham wrote:
>> 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.
>
> Right. That's difficult. It could just be anything...
> A kind of related issue is that Mozilla apps still ignore <link
> rel="next"> and similar head items. Adding some buttons (maybe a
> separate optional toolbar or something) could solve this issue (not
> from anti-phishing point of view, though). Also, see below.
>
Firefox had a site navigation bar a long, long time ago and it was dropped.
SeaMonkey still having one.
Well... most pages don't use navigation links.
Even pages that follow the next, previous, up, top structure makes use
of this.
If you find some good place at the UI, let us know.
Asrail
> 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
>
> Now consider a URL with 30 %20's. If unescaped, these would be
> displayed as spaces. And as the URL bar only has finite length (say,
> 40 symbols, and then text flows out), and no scrollbar, you'll simply
> NOT know that the URL you see is incomplete. That's a good phishing
> opportunity, IMO. Don't you think so?
URL should be escaped. If there are issues like this, they should be fixed.
A indicator that the visible area has been overflowed would be a good
option.
> This should be thought of before unescaping characters. BTW, how does
> Firefox handle IDN currently?
Nicely.
Tony Mechelynck
[...]
> Firefox had a site navigation bar a long, long time ago and it was dropped.
> SeaMonkey still having one.
Never knew Firefox ever had one. I like SeaMonkey's, even if I can only use it
on the Bugzilla site.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
42. Your virtual girlfriend finds a new net sweetheart with a larger bandwidth.
Rimas Kudelis
>> Gervase Markham wrote:
>>> 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.
>>
>> Right. That's difficult. It could just be anything...
>> A kind of related issue is that Mozilla apps still ignore <link
>> rel="next"> and similar head items. Adding some buttons (maybe a
>> separate optional toolbar or something) could solve this issue (not
>> from anti-phishing point of view, though). Also, see below.
>>
>
> Firefox had a site navigation bar a long, long time ago and it was dropped.
> SeaMonkey still having one.
Hmm... Never saw it. OK.
> Well... most pages don't use navigation links.
Because most browsers ignore them. ;)
> Even pages that follow the next, previous, up, top structure makes use
> of this.
Well, on the other hand, most pages have their own way of going up, so
it's probably not so much in a need. I don't know... Anyways, same
applies to the hostname button still.
> If you find some good place at the UI, let us know.
The problem is probably not where to put those buttons, but how to
distinguish them from already existing "Back", "Forward" and "Home"
buttons... Furthermore, separate toolbar is probably not the best
thing, as it may clutter UI (I have installed Web Developer and
Operator at work, and it already looks cluttered with the total of
five toolbars including menu).
The short answer is "I don't know for sure".
RQ
Kim Sullivan
> Now consider a URL with 30 %20's. If unescaped, these would be
> displayed as spaces. And as the URL bar only has finite length (say,
> 40 symbols, and then text flows out), and no scrollbar, you'll simply
> NOT know that the URL you see is incomplete. That's a good phishing
> opportunity, IMO. Don't you think so?
You're right that so many spaces are something that needs to be
handled (maybe visualise long strings of whitespace), but I'm not sure
if it's really a phishing opportunity because un-escaping %20 should
only happen in the file part of the url, not in the query part - and
since most URL based phishing attacks try to either spoof the domain
(which is handled elsewhere in the IDN code), or use a publicly
acessible redirect, it would be a bit tricky.
You'd basically need some url like
which is almost equally susceptible to phishing, because, well, do you
really think that ordinary users will try to decipher a long string of
"some garbage with numbers and % signs"? Also, since the %20 have to
be in the "path", you'd need some really stupid url-handling rules to
be able to do that... so let's suppose they have, and the above is a
valid path, which would be rendered like
www.somebank.com/path/to/redirector/ ?
url=http://xx.xx.xx.xx/steal-login
Why not display such overly long strings of whitespace in the filename
using the middle dot (as is commonly done in word processors with the
"show whitespace" option turned on):
www.somebank.com/path/to/redirector/······························?url=http://xx.xx.xx.xx/steal-login
There is another even simpler option: don't unescape whitespace (Opera
does this like that). It's probably the simplest solution, and I think
it's an acceptable trade-off between URL readability, and security
(and normal sites won't usually have more than a few %20 in their url
anyway, and those that care will have replaced them with - or _).
Asrail
> Asrail wrote:
>>> Right. That's difficult. It could just be anything...
>>> A kind of related issue is that Mozilla apps still ignore <link
>>> rel="next"> and similar head items. Adding some buttons (maybe a
>>> separate optional toolbar or something) could solve this issue (not
>>> from anti-phishing point of view, though). Also, see below.
>>>
>>
>> Firefox had a site navigation bar a long, long time ago and it was dropped.
>> SeaMonkey still having one.
>
> Hmm... Never saw it. OK.
It was before 1.0, I'm sure. I don't know until which version (maybe it
wasn't even called Firefox), but it had one (I can look at the FTP site
and show an example).
>> Well... most pages don't use navigation links.
>
> Because most browsers ignore them. ;)
Opera don't, SM don't, FX dropped... I think you meant "because IE
ignores them".
>> Even pages that follow the next, previous, up, top structure makes use
>> of this.
>
> Well, on the other hand, most pages have their own way of going up, so
> it's probably not so much in a need. I don't know... Anyways, same
> applies to the hostname button still.
Move to another page magically based on numbers near the end of the URL
was proposed some time ago as one features for this extension.
I think that the navigation links are useful. One could assign shortcuts
for these with a extension, for instance.
>> If you find some good place at the UI, let us know.
>
> The problem is probably not where to put those buttons, but how to
> distinguish them from already existing "Back", "Forward" and "Home"
> buttons... Furthermore, separate toolbar is probably not the best
> thing, as it may clutter UI (I have installed Web Developer and
> Operator at work, and it already looks cluttered with the total of
> five toolbars including menu).
Yet another toolbar is the SM approach. I dislike it and would like to
see some improvement on that area. We shouldn't transform the URL bar in
a "Emacs minibuffer", as joked a friend of mine, but may to exist some
way of adding functionality without confusing the UI or being hard to use.
Asrail
> Asrail wrote:
> [...]
>> Firefox had a site navigation bar a long, long time ago and it was
>> dropped.
>> SeaMonkey still having one.
> [...]
>
> Never knew Firefox ever had one. I like SeaMonkey's, even if I can only
> use it on the Bugzilla site.
>
View --> Show/Hide --> Site navigation bar
;)
Yeah, that works fine with bugzilla.
Rimas Kudelis
>>>> Right. That's difficult. It could just be anything...
>>>> A kind of related issue is that Mozilla apps still ignore <link
>>>> rel="next"> and similar head items. Adding some buttons (maybe a
>>>> separate optional toolbar or something) could solve this issue (not
>>>> from anti-phishing point of view, though). Also, see below.
>>>>
>>>
>>> Firefox had a site navigation bar a long, long time ago and it was
>>> dropped.
>>> SeaMonkey still having one.
>>
>> Hmm... Never saw it. OK.
>
> It was before 1.0, I'm sure. I don't know until which version (maybe it
> wasn't even called Firefox), but it had one (I can look at the FTP site
> and show an example).
No need for that, I believe you. :)
>>> Well... most pages don't use navigation links.
>>
>> Because most browsers ignore them. ;)
>
> Opera don't, SM don't, FX dropped... I think you meant "because IE
> ignores them".
Yes, IE ignores them, and that alone constitutes a vast majority of
web users. However, the next most popular browser, Firefox, now
ignores them too, and it's irrelevant if it supported those buttons
back in Phoenix 0.5 or not. That was a long time ago, when it didn't
have its current userbase. Safari, the default browser for Mac, also
doesn't have this functionality, Konqueror either. What remains is
Opera, which is way less popular than Fx, and Sm, which has like
err... 0% of total userbase?.. That's not much to worry about...
Btw, I think Opera is mostly used by people who consider themselves
power users, and people like these rarely complain about missing
features like the one I'm talking about... :)
>>> Even pages that follow the next, previous, up, top structure makes use
>>> of this.
>>
>> Well, on the other hand, most pages have their own way of going up, so
>> it's probably not so much in a need. I don't know... Anyways, same
>> applies to the hostname button still.
>
> Move to another page magically based on numbers near the end of the URL
> was proposed some time ago as one features for this extension.
Yeah. Imagine it increasing the value of PHPSESSID :) I think such
functionality is probably OK for an extension, but it definitely
shouldn't go into mainstream Firefox.
> I think that the navigation links are useful. One could assign shortcuts
> for these with a extension, for instance.
If you're talking about <link rel="next"> etc, then I agree. But
again, it possibly clutters the UI, and is rarely used by website
owners... One of the reasons for that is that websites are tree-like,
and it would be quite hard to put them into a single row logically.
The two cases where I see such links working would be:
1) paged articles (which are often misused anyway, IMO);
2) small websites with, say, 5 pages total.
However, I hardly imagine myself enumerating pages of the website of
my university into some sequence...
>>> If you find some good place at the UI, let us know.
>>
>> The problem is probably not where to put those buttons, but how to
>> distinguish them from already existing "Back", "Forward" and "Home"
>> buttons... Furthermore, separate toolbar is probably not the best
>> thing, as it may clutter UI (I have installed Web Developer and
>> Operator at work, and it already looks cluttered with the total of
>> five toolbars including menu).
>
> Yet another toolbar is the SM approach. I dislike it and would like to
> see some improvement on that area. We shouldn't transform the URL bar in
> a "Emacs minibuffer", as joked a friend of mine, but may to exist some
> way of adding functionality without confusing the UI or being hard to use.
Maybe one of the problems is that Firefox/Thunderbird don't allow
stacking toolbars next to each other (like classic MS Office does). Do
I really need 19 centimeters of space for the URL bar in Firefox? I
doubt it. ;)
BTW, it's a bit weird that I can easily add a new toolbar, but not
remove one... :)
RQ
Tony Mechelynck
You can move any widgets from one toolbar to another, to the menu bar, or
altogether off the screen.
>
> BTW, it's a bit weird that I can easily add a new toolbar, but not
> remove one... :)
>
> RQ
View => Toolbars => click a toolbar name to remove the check mark. From then
on it won't be displayed.
Best regards,
Tony.
--
Oh, wow! Look at the moon!
Rimas Kudelis
> Rimas Kudelis wrote:
>> BTW, it's a bit weird that I can easily add a new toolbar, but not
>> remove one... :)
>
> then on it won't be displayed.
But it won't be deleted. :) Well, maybe not everyone needs it OTOH...
RQ
Asrail
>
> You'd basically need some url like
>
> www.somebank.com/path/to/redirector/%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20?url=http://xx.xx.xx.xx/steal-login
>
I don't believe any ordinary user would pay attention to the redirect
part. Mainly because that could/should looks like:
q=http%3A%2F%2Fxx.xx.xx%2Fsl
instead of the obvious steal one.
Tiny URL and alike are as dangerous as this one and not phishing domains
shouldn't allow arbitrary redirects.
Google allow redirects for the pages that appear on their search
(changing the URL redirects you to a notice page).
But the ordinary users pay attention to what they see and won't read
long URLs at all.
We should add security by not allowing the user to be
infected/threatened just by visiting the page and he would see the wrong
domain there, anyway.
>
> Why not display such overly long strings of whitespace in the filename
> using the middle dot (as is commonly done in word processors with the
> "show whitespace" option turned on):
> www.somebank.com/path/to/redirector/······························?url=http://xx.xx.xx.xx/steal-login
>
> There is another even simpler option: don't unescape whitespace (Opera
> does this like that). It's probably the simplest solution, and I think
> it's an acceptable trade-off between URL readability, and security
> (and normal sites won't usually have more than a few %20 in their url
> anyway, and those that care will have replaced them with - or _).
>
Allowing the user to copy is good. Wikipedia accepts "%20" or "_", so
both would work, but a lot of sites only allow "%20" to represent spaces.
So changing it to something else would stop copy and past.
Changing from "·" to "%20" on mouseover is not pretty.
Version 0.8 of the scrollbar does not changes the look of the text URL
on mouseover, only the visual style.
You could give a try to different versions and see what features make it
less comfortable to browse (moving things too much and changing a lot of
other things would gave me a headache).
Greg Campbell
> 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.
I'll look into my crystal ball then...
Ahhh. 4 groups:
1. Novice users never looked at the location bar and still don't. The
only thing they use above the content area is the back button, the
window close button, and maybe the print button (but probably not, since
it's stupidly not in the default set). They might notice that "the
Internet looks a little different now," but they won't really care. Most
everything up above the content area is scary.
2. Moderately advanced users will be annoyed at the change since they
(at least vaguely) understood how the location bar worked previously.
They don't like change. Or they'll feel like things are being dumbed down.
3. Very advanced users will appreciate how the changes could help their
"educated novice" family members. (see group 4)
4. The last group is the "educated novices." These are the users who
would belong to group 1, but have family belonging to group 3. They have
been told what to look for to avoid getting caught by phishing scams.
They err on the safe side and don't use their bank's website if anything
looks a little different from how they remember things last time. They
also like to forward scam emails with the message "Is this real?"
These proposed changes to the location bar may benefit these users in
the long run, but the actual benefit comes to group 3: group 4 will call
group 3 on the phone less frequently with questions. Group 3 WILL have
to spend time re-educating group 4 on how to understand the new features
since anything that--even subtly--looks different will potentially seem
like a huge change to group 4.
**Disclaimer**
I don't mean to discourage the efforts of those persons working on these
changes.
Greg
Kim Sullivan
> > Why not display such overly long strings of whitespace in the filename
> > using the middle dot (as is commonly done in word processors with the
> > "show whitespace" option turned on):
> >www.somebank.com/path/to/redirector/······························?url=http://xx.xx.xx.xx/steal-login
>
> > There is another even simpler option: don't unescape whitespace (Opera
> > does this like that). It's probably the simplest solution, and I think
> > it's an acceptable trade-off between URL readability, and security
> > (and normal sites won't usually have more than a few %20 in their url
> > anyway, and those that care will have replaced them with - or _).
>
> Allowing the user to copy is good. Wikipedia accepts "%20" or "_", so
> both would work, but a lot of sites only allow "%20" to represent spaces.
> So changing it to something else would stop copy and past.
I didn't mean to actually change it, just display a different
character than would be copied. I'm all for copying. I've been
thinking about another issue with copying URLS - copy the escaped or
unescaped URL? I mean, sometimes you want to directly use the address
as a target for a link, in which case you want the escape sequences.
In other cases, you want to copy the URL so it will be human readable
later, so you really want to copy the characters, and not the escape
sequences.
I think that a hover menu (that appears below the location bar, and
doesn't change the text or look of the text in the address) would be a
lot more flexible than trying to fit everything in a single line.
Whatever the final decision will be, it should consistent with how
URLs are displayed in the status bar. Currently, they are displayed
unescaped (which is good), including spaces (which is not so good).
Rimas Kudelis
Think of the third case – when you don't really care at all about the
way your URL would be copied. I think this is the most common scenario.
I wouldn't really want to get a hover menu each time I want to copy
something. That's rude. Maybe a simple about:config variable would do,
leaving context menu stuff to some extension?
RQ
Gervase Markham
> 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.
Possibly. But that still leaves the question of what the default is.
Also, for UI which has a security dimension, consistency across browser
versions is important. So ideally we would pick one style that worked
everywhere and stick to it.
Gerv
Gervase Markham
> 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.)
Press Ctrl-L and start typing?
Gerv
Gervase Markham
> On Feb 16, 3:37 pm, Gervase Markham <g...@mozilla.org> 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).
>
> We could use colour, in fact we could make it blue and underlined like
> a link.
We could. Conceptually, that makes some sense, but I can't help thinking
it would confuse people in practice.
> (each directory in the URL could also be a link, styled similarly that
> leads to that directory).
But then the domain would no longer be distinctively styled.
Peter Lairo
Discoverable? Easily discoverable? Complies with usage habits?
--
Regards,
Peter Lairo
Lame attempt to get rich: http://www.lairo.com/donations.html
Gervase Markham
> 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).
As Ben says, that's the idea. We specifically don't want people to think
they are more secure.
> And if there is additional
> functionality like in the case of ftp it would be nice to know that too.
Then, when and if such functionality appears, we should provide
understandable UI that shows that. As Ben also points out, we can
theoretically provide upload capabilities for both HTTP and FTP.
Let's use upload as an example. Saying "If you want to know if you can
upload, look for 'ftp://' in the URL bar" is not particularly good UI.
There's no mental connection for most people between the ability to
upload and the six weird characters 'ftp://'. You would describe the UI
that way only because that's all there would be to indicate that this
capability is available.
> 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).
Then that's a bug in Google's site. :-)
> 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.
Really? Do people type out entire URLs because copy and paste is beyond
them? I know we have to take account of all users, but it seems to me
that it would be very difficult to use any application on a computer
these days without some notion of the idea of 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...
Perhaps. But you will admit this is a very niche case.
Gerv
Gervase Markham
> 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.
They might. What's the worst that happens? The URL bar does a search on
the business name with the default search provider, and most of the time
they'll get to where they want to go quite soon.
Remember also the name button might have a flag, which of course they
can't type in. The use of an icon perhaps makes it more obvious that
this is not something you can type yourself.
Gerv
Gervase Markham
> What should you have to be able to drag the URL to the bookmarks or some
> tab? It was just an idea.
That's a good question. We'd certainly need to consider that.
We could just stop putting the favicon there and always have it as the
default blank sheet of paper. But then it's more likely that people
would consider that the browser is broken.
>>> 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).
Perhaps we need to make the protocol visible in the full text version...
>> 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?
Again, a good point.
Gerv
Gervase Markham
> 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:
Right - but this has basically no bearing on the question, because even
if we provided UI for changing the font, users would a) probably never
change it, and b) if they did, they'd change it for a font that looked
prettier, not one that was more secure.
We need to choose the font, and we need to make the correct choice for
security.
Gerv
Gervase Markham
> I do, actually. Exactly the way Michael described (https for webmail
> and admin tasks, http for main webpage). And I'm sure I'm not the only
> one.
Why? Why not use different hostnames? Is it too inconvenient for you to
change the DNS to have two aliases for the same machine?
Gerv
Gervase Markham
> 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.
It's not about "wanting a flag", it's about indicating the jurisdiction
under which the company works in order to disambiguate names. And the
flag is not generated from the TLD, it's generated from the C field of
the certificate (which might be different).
Still, I'm sure that extension would be a good source of flag icons :-)
Gerv
Gervase Markham
> 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/
Right - the page title does. Which is not affected by this proposal.
> statusbar/etc. Without seeing the domain in the statusbar, there's
> less reinforcement of site identity.
I'm not sure what you mean here. Are you talking about the domain
indicator in the bottom right?
> 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.
All good points. If the scheme were hidden, I would expect it to be
added to the copy whenever the selection started at the left hand end of
the URL bar.
> 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.
I'm beginning to agree with you.
> 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.
A good point.
Gerv
Gervase Markham
> 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.
Remember, this only happens for SSL connections, not for plain HTTP
connections like the ones to Google. And, if both connections were over
HTTPS, it's quite likely (although not guaranteed) that the flags would
be different.
> 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.
That's really interesting.
> 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.
Yes, it should be themeable, just like anything else. But ideally the
default would be the same for all locales, as that's what 99% of people
will use.
Gerv
Gervase Markham
> 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.
That's certainly an interesting idea.
Gerv
Gervase Markham
> 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.
Remember, this substition is only for HTTPS.
> 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.
We could. That's a more radical change, but it's perhaps consistent.
After all, most users see it as a jumble of confusing characters...
>> 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.
Different sites, yes. But controlled by different people who are not
mutually trusting?
Where would you find a server where I have a website on port 80 and Mr.
Evil, who I don't know and don't trust, has a website on port 90?
> 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).
Myk suggested highlighting it if not the default.
>> 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?
It's a different sort of distinguishing. It's about distinguishing what
you are doing, as opposed to on whose site you are doing it.
I want to distinguish whether I'm on my bank's site or a spoof of my
bank's site by looking at the domain indicator. Sure. But then, I
distinguish whether I'm editing my account or reading about mortgages by
looking at the content area. This point is almost too obvious to be
worth making. How do you know what you are doing on the web? By what the
content area says. If it's got lists of emails, I'm looking at my inbox.
If it's a single email, I'm reading one.
>> 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?
I don't know what you mean by that. You mean from the discussion, or
from the product? :-)
> 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.
That is true, at the moment. But ideally, the highlight method we use
should be future-proof. I don't want to have to switch highlight methods
depending on the exact combination of characters in the domain name.
Gerv
Gervase Markham
> 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.
>
> between buttons, or in the white space at the left or right ends.
But are people really going to rememeber to do that?
I realise this argument is also an argument against making the domain
name clickable.
>> * 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.
>
> - 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.
Indeed - and I think it would be hard to unambiguously indicate to the
user that the list was not exhaustive.
Gerv
Nelson Bolyard
> 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).
>
who is "we"?
> 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.
>
Gervase Markham
> 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.
One way is to press Ctrl-L and start typing. Ctrl-L will still focus the
URL bar and select all the contents.
> 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 would hope that would continue to work; I don't see why it wouldn't.
> 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.
This is the "merge location bar and search box" proposal. I used to
think this was a great idea myself, but I've moved away from it as the
search box has acquired more function (e.g. selecting search providers
from a dropdown, autocomplete of search terms) which it would be hard to
put into the URL bar without making it insanely complex.
> 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.
If we put other text in place, it's possible that people will try to
type it instead of the real thing. And then we have to recognise it. And
then they do it in other browsers and wonder why it doesn't work. And we
either have a compatibility problem, or we have invented a new /de
facto/ alternative for "http://", which is "web:".
> 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 would be concerned that such a multi-modal URL bar would be hard for
users to understand. Perhaps one of my goals should be: "not increase
complexity".
Gerv
Gervase Markham
> How extensive should this be to keep the interface consistent?
_Very_ good point.
> Examples of other places to recplicate the hostname emphasis.
> - History entries in autocomplete dropdown
Yes, we should do that.
> - Status bar (setting the status bar to be some text would not trigger
> the emphasis)
Well, we disable the ability to set the status bar text now anyway. But
yes, URLs in the status bar should have the same emphasis if possible.
> - URL bar (as you type - instant notification if you mistyped)
Good stuff too.
> - Bookmarks
Well, normally the URL isn't displayed, is it?
But the big point here is that if the highlighting is going to be
present throughout the UI, and if it is going to be consistent, then we
have to use a text style which works in places which are much more
"text-y". In other words, we sort of have a choice of bold, italic,
underline or some combination of the three.
Gerv
Gervase Markham
>> - 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
I believe Locationbar2 does this already. I was worried about it to
start with, but I'm beginning to like it. As long as it switches back on
focus.
There are standards for this sort of thing, I believe - IRIs and so on.
>> 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).
But people write "www.mozilla.org" or similar on post-it notes all the
time, and the world doesn't stop spinning. If you type "www.mozilla.org"
into the URL bar of a browser, you'll end up in the right place.
The only place "http://" becomes important is for people hand-editing
HTML. Does your grandmother do that? If she does, she should know about
URL schemes.
> 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).
Firefox already tries FTP first for hosts whose name is "ftp".
Gerv
Gervase Markham
> Now consider a URL with 30 %20's. If unescaped, these would be
> displayed as spaces. And as the URL bar only has finite length (say,
> 40 symbols, and then text flows out), and no scrollbar, you'll simply
> NOT know that the URL you see is incomplete. That's a good phishing
> opportunity, IMO. Don't you think so?
Not really. Because it only gives the opportunity to hide what the URL
is _within_ a particular domain - and all that content should be under
the control of the same person. Phishing relies on confusion about the
domain.
Gerv
Gervase Markham
> Responding to your proposal. I may also post my own one here again.
>
> Gervase Markham wrote:
>> 1) Hide the scheme
>
> Agreed.
Ben - I'm glad that you agree with so much of the proposal. I'm
focussing on the bits you disagree about in this reply only because
there's not much point discussing the things we agree on! :-)
> 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.
I don't think we have any plans to disable IDN. But I agree, there is
potentially a homograph problem which would need to be solved again. The
jurisdiction indicator mitigates this to a certain extent.
> * There's a whole new way to have phishing with similar or confusing
> names, e.g. eBay Helpers, Inc..
I'm not sure that would pass the "human sanity check" part of the EV
process.
> * Many company may have a real name that is not easily recognizable,
> making people just accept anything even more than they do now!
That is certainly a risk. There are particular problems with this in
Japan, where often the official English transliteration of the Japanese
name is not the same as the name everyone knows the company by. For
example, Sony's Japanese name officially transliterates to "Sonii
Corporation". Does that look like a phishing attempt to you? :-)
In this case (Japan), the EV people are working on a way to authenticate
the name everyone really knows the company by, so that it can be put
into the relevant field. But I agree there's a concern.
> * 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>.
Are any two in the same country?
> 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.
Now that's an interesting idea.
>> 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.)
I think we definitely want to improve the discoverability of tabs, and
encourage people to use them more, yes.
As monitor sizes get bigger, the "screen real estate" argument fades
into the background a bit.
> Also, favicons in tab headers are still in chrome.
True, but they are in an area of the chrome which is both right next to
the content area, and already filled with content from it (page titles).
> I'd suggest to drop this change from the proposal, it's only vaguely
> related.
It's certainly not tied in tightly. But I think it's worth keeping it as
part of the same discussion, because it combats a possible disadvantage
of another idea.
Gerv
Kim Sullivan
> > I think that a hover menu (that appears below the location bar, and
> > doesn't change the text or look of the text in the address) would be a
> > lot more flexible than trying to fit everything in a single line.
>
> Think of the third case – when you don't really care at all about the
> way your URL would be copied. I think this is the most common scenario.
I think that it's not really a question about caring or not, I believe
people want it to just work. Unfortunately, URIs/URLs are defined in a
way that prevents this, because they require non us-ASCII octets to be
encoded with percent signs, which is contrary to what users want (or
at least so I believe), namely readable URLs.
The problem is that
http://ja.wikipedia.org/wiki/メインページ is not really a valid URL (at
least the way I nunderstand the RFC spec), allthough Opera, IE and FF
seem to handle it OK if it's a part of a link (and the w3c validator
accepts it as well).
So, using character sequences all the time (on display and on copy/
paste) would probably work well enough - completely hiding the fact
that there is something as an encoding scheme using percent signs and
hex numbers (except for whitespace).
> I wouldn't really want to get a hover menu each time I want to copy
> something. That's rude. Maybe a simple about:config variable would do,
> leaving context menu stuff to some extension?
You're right - being able to use the adress bar as a text field (copy/
paste, editing) is important. The hover menu was just an idea, because
there seem to be contradicting suggestions - people want to be able to
select and edit and copy/paste the adress as usual, and at the same
time they would like to have parts of the url active as buttons,
displaying EV (whatever that means), and I think you can't really have
both at the same time (the current LocationBar2 extension nicely shows
that, to be able to edit something you first have to actually click on
a part of the URL)
Kim
Gervase Markham
> However, I'm not against stripping the "username:password@" part from
> the URLs.
That's all I meant. :-)
> Now, here's the "below" part. Have you seen IE7? It adds a small
> clickable field with a lock for secure sites. Now we could have
> something similar. Why not PREPEND an EV (WTF is EV?) information
> instead of replacing the domain name with it?
You are the second person to suggest that (after Ben). It's certainly an
interesting idea.
Gerv