Dão Gottwald [:dao] Assignee
	Description • 18 years ago

From <http://wiki.mozilla.org/Firefox/Feature_Brainstorming:Addressbar>:

> When nonlatin characters are used in address they are urlencoded.
> Many sites use them. Wikipedia is an example. But URL shown in an
> addressbar gets totally unreadable, like
> http://uk.wikipedia.org/wiki/%D0%92%D1%96%D0%BA%D1%96%D0%BF%D0%B5%D0%B4%D1%96%D1%8F.
> 
> Such URL is not an easy thing write down on paper for example. It would
> be nice if such URLs were shown more like this (the non-latin part could be
> highlighted or formatted to prevent phishing):
> http://uk.wikipedia.org/wiki/Вікіпедія

And:

> Make the domain name within the URL bold or otherwise highlighted to reduce
> the spoofing risks of complex URLs.

Based on those suggestions, I've created the "Locationbar²" extension:
http://en.design-noir.de/mozilla/locationbar2/

I tried to keep it simple (no fancy colors like some users requested) and make it useful for both novices and experienced users. Besides some early bugs that are fixed now, I got only positive responses (avg. rating on AMO is 5.0). Thus I'm asking if such an enhancement could make it into, say, Firefox 3.

	Dão Gottwald [:dao] Assignee
	Comment 1 • 18 years ago

I think what backs it up best is this AMO comment:

> First time I downloaded this extension I found it useless.
> 1 week after I installed I had to format my PC, after that I installed Firefox
> and missed something. Guess what? This extension.
> Believe me, this extension helps a lot. Not just for me, for my father too.


Note that the extension works differently on trunk and 1.8 branches. It tries to use Effective TLD Service <http://wiki.mozilla.org/Gecko:Effective_TLD_Service> and then makes only the main domain bold, otherwise the entire hostname.

	Dão Gottwald [:dao] Assignee
	Comment 2 • 18 years ago

Since at least nobody disagreed actively, here's my first try.

I'm not sure if toolkit is the right place for the new binding, and if browser.css is the right place for assigning it to #urlbar.

I was going to ask Simon Bünzli for a first review, but apparently he's not available.

Regarding UI review: I guess you can also use the extension for that, it looks the same. Plus it has a preferences UI, so you could easily test what would be good default values.

	Dão Gottwald [:dao] Assignee
	Comment 3 • 18 years ago

Comment on attachment 251477 [details] [diff] [review]
patch

Err, I wonder what that means:

>+++ base/content/browser.js	14 Jan 2007 23:44:13 -0000
>@@ -1,4 +1,4 @@
>-# -*- Mode: Java; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*-
>+# -*- Mode: Java; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*-

	Mike Connor [:mconnor]
	Comment 4 • 18 years ago

I've been running with the latest version of this for a few days, I'm not sure I like the interaction, visually its interesting, but trying to click into a URL is jarring and frustrating.  Let's not jump ahead too fast here, though I think it shows promise.

	Dão Gottwald [:dao] Assignee
	Comment 5 • 18 years ago

(In reply to comment #4)
> trying to click into a URL is jarring and frustrating.

It's a price I was willing to pay after some hours. It slightly changed the way I click into URLs (i.e. set the focus first, then look for the target position) and now I hardly notice a difference. Also, I expect that editing URLs partly is not a common task for the average user.
Nevertheless, it's certainly not optimal, and if someone could come up with one or two fresh ideas, that would be great.

	Alex
	Comment 6 • 18 years ago

Assuming this is incorporated into Firefox 3, when editing the URL manually can it be coded so you can edit the bold type (i.e.- without making the URL bar revert to normal when focused; keep the domain bold if opted)? That would make it easier to edit instead of having to focus onto the URL bar.

	Dão Gottwald [:dao] Assignee
	Comment 7 • 18 years ago

(In reply to comment #6)
You couldn't copy the original URL then. That's pretty bad.

	Dão Gottwald [:dao] Assignee
	Comment 8 • 18 years ago

some code cleanup, adding browser.urlbar.decode

I've picked gavin and beltzner randomly; feel free to change the review requests.

An unrelated note: I feel that "gapingSpaces" is bad English, but didn't have a better idea ... maybe "innerSpaces"?

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 9 • 18 years ago

Comment on attachment 251704 [details] [diff] [review]
patch 2

I liked this more than I thought I would. While not an overly radical simplification of the URL field, I think it works rather well. 

I'm not sure that this is ready to land on trunk yet. Some quick suggestions, more to come (and potentially a blog post!)

 - use "separator spaces" instead of "gaping spaces"

 - when restoring the full URI for editing, we should put the cursor where they clicked so the interaction is seamless

 - I wonder if it might be worth exploring an option to truncate the path portion to fit in the location bar, so we'd see:

O mozilla.org /projects/.../filename.html

	Dão Gottwald [:dao] Assignee
	Comment 10 • 18 years ago

(In reply to comment #9)
>  - I wonder if it might be worth exploring an option to truncate the path
> portion to fit in the location bar, so we'd see:
> 
> O mozilla.org /projects/.../filename.html

I think that's a counter-example, because the removed portion is at least as interesting as the filename.

	Dão Gottwald [:dao] Assignee
	Comment 11 • 18 years ago

(In reply to comment #9)
>  - when restoring the full URI for editing, we should put the cursor where they
> clicked so the interaction is seamless

I tried to save the cursor position (this.inputField.selectionStart), but that's 0 when you click on the domain node (html:strong). I guess you would have to replace urlbar's <html:input/> with <xul:editor/> in order to solve this, but I'm not sure.
I could also save the pointer position of the click event. Would it be possible to emulate a new click afterwards?
Any other ideas?

Note that this only affects Unix (browser.urlbar.clickSelectsAll = false).

	Dão Gottwald [:dao] Assignee
	Comment 12 • 18 years ago

notes:

  - Using a dirty timeout, because click is dispatched way after focus.

  - Click doesn't reach the event listener at all if you click on the text,
    which rattens the whole approach.

  - Disable "strong domain" in order to see how it should work. Even that
    is suboptimal, because the characters have different widths.

synced extension: http://design-noir.de/mozilla/locationbar2/0.3.7.2.xpi

	Dão Gottwald [:dao] Assignee
	Comment 13 • 18 years ago

>   - Click doesn't reach the event listener at all if you click on the text

... because the target node doesn't exist anymore after plainView()

	Dão Gottwald [:dao] Assignee
	Comment 14 • 18 years ago

>   - Using a dirty timeout, because click is dispatched way after focus.

ugly hack removed, although the click event is still late (I would expect that it's dispatched *before* focus.)

>   - Click doesn't reach the event listener at all if you click on the text,
>     which rattens the whole approach.

fixed

>   - Disable "strong domain" in order to see how it should work. Even that
>     is suboptimal, because the characters have different widths.

fixed

synced extension: http://design-noir.de/mozilla/locationbar2/0.3.7.3.xpi

	Dão Gottwald [:dao] Assignee
	Comment 16 • 18 years ago

Now there's a bug if the location bar didn't have focus and you start selecting.

	Dão Gottwald [:dao] Assignee
	Comment 17 • 18 years ago

Oh, and Ald+D / F6 are broken.

	Dão Gottwald [:dao] Assignee
	Comment 18 • 18 years ago

Alt+D

	Dão Gottwald [:dao] Assignee
	Comment 19 • 18 years ago

Comment on attachment 251787 [details] [diff] [review]
WIP 4 (had typo)

I suppose that will perform better with the mousedown event.

	Dão Gottwald [:dao] Assignee
	Comment 20 • 18 years ago

synced extension: http://design-noir.de/mozilla/locationbar2/0.3.7.4.xpi

	Dão Gottwald [:dao] Assignee
	Comment 21 • 18 years ago

I probably misunderstood comment 4, because I had clickSelectsAll set to true. Anyway, that should now be fixed or at least not _that_ frustrating.

	Dão Gottwald [:dao] Assignee
	Comment 22 • 18 years ago

moving from themes to xul.css

	Dão Gottwald [:dao] Assignee
	Comment 23 • 18 years ago

diff was broken

	Dão Gottwald [:dao] Assignee
	Comment 24 • 18 years ago

Comment on attachment 251931 [details] [diff] [review]
patch 6

>+        this.inputField.addEventListener("mousemove", function(event) {
>+          if (self._focused && select) {
>+            var selectionEnd = self._getCursorPosition(event);
>+            if (selectionStart < selectionEnd)
>+              this.setSelectionRange (selectionStart, selectionEnd);
>+            else
>+              this.setSelectionRange (selectionEnd, selectionStart);
>+          }
>+        }, false);

While this feels just like normal selecting on my Windows builds (both trunk and branch), it's rather sluggish Firefox 2 / Ubuntu. I wonder if that's better on trunk.

	jasir
	Comment 25 • 18 years ago

small, simple, sweet, superb!

if i'm not asking too much, may be an option to hide the long unimportant parts of urls that continue after .php, .cgi, etc. That's not required for a normal user. Ofcourse you may make it optional.

for eg,
http://mail.google.com/mail/?zx=t3o2avjrs3vu&auth=DQAAAHgAAADYGfSxNd....
may be simplified as:
mail.google.com /mail/~

or something ending like:
http://abc.com/index.php?crumb=huJG5Ruh9qP....
or https://addons.mozilla.org/search.php?app=firefox&type=E&appfilter=fi...
may be reduced to
abc.com /indiex.php~ and addons.mozilla.org /search.php?~

Also, many be shorten long urls with lots of "/"s to something like:
www.abc.com /files/~/ page1.html

where ~ is used to denote that a portion is hidden.

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 26 • 18 years ago

It's certainly maintaining some form of cursor position when I click now, but it seems to not be taking into account the offset of restoring the protocol string (http://, https://) and so I'm a little off to the side of where I expect to be. 

Other than that it seems to work well!

	Dão Gottwald [:dao] Assignee
	Comment 27 • 18 years ago

(In reply to comment #25)
I don't like both suggestions (see comment 10 for one reason), but I could implement them.

What should be considered as well is to make this extensible in a clean way, i.e. not expecting developers to overwrite prettyView().

(In reply to comment #26)
Currently, it places the cursor wherever your mouse pointer is. Subtracting the width of the protocol would be easy. But with the strong domain, the spaces and the decoded part, it would remain a moving target.

	jasir
	Comment 28 • 18 years ago

(In reply to comment #27)
I understand.
But then why not giveita try? 
Make them optional features?

	Dão Gottwald [:dao] Assignee
	Comment 29 • 18 years ago

(In reply to comment #26)
> It's certainly maintaining some form of cursor position when I click now, but
> it seems to not be taking into account the offset of restoring the protocol
> string (http://, https://) and so I'm a little off to the side of where I
> expect to be.

Another idea: what about switching to the plain view on mouseover? That would also fix the performance issue (comment 24).


(In reply to comment #28)
> I understand.
> But then why not giveita try?

Maybe later, I'd like to fix real showstoppers first (but it's not my decision anyway).

	Dão Gottwald [:dao] Assignee
	Comment 30 • 18 years ago

http://design-noir.de/mozilla/locationbar2/0.4.xpi

	Dão Gottwald [:dao] Assignee
	Comment 31 • 18 years ago

no behaviour change

	Dão Gottwald [:dao] Assignee
	Comment 32 • 18 years ago

username:password@ is always removed from URLs before the location bar gets them, isn't it? In that case I'll remove the corresponding part.

btw, in order to test that, I opened
data:text/html;,<a href="http://anonymous:anonymous@mozilla.com">x</a>

The patched location bar thinks, data:text/html;,<a href="http:// would be the protocol and mozilla.com">x< the host ... I'll have to update the URL parser regexp.
Or is there a service I could utilize?

	Dão Gottwald [:dao] Assignee
	Comment 33 • 18 years ago

see comment 32

	Dão Gottwald [:dao] Assignee
	Comment 34 • 18 years ago

-> http://design-noir.de/mozilla/locationbar2/0.4.1.xpi

	Dão Gottwald [:dao] Assignee
	Comment 35 • 18 years ago

was flawed

	Daniel Veditz [:dveditz]
	Comment 36 • 18 years ago

(In reply to comment #32)
> I'll have to update the URL parser regexp.
> Or is there a service I could utilize?

You should use nsIURI instead of the location element (e.g. gBrowser.currentURI instead of gBrowser.contentDocument.location). nsIURI::scheme will always be exactly what the network engine interprets as the scheme.

I was going to suggest you should also be using currentURI.asciiHost to get the punycoded version of the hostname (can't get that from location) on the assumption the EffectiveTLD service requires it. It does specify using stringprep (rfc 3454) but not full IDN and even says UTF-8 is used in the file.

That's a bit confusing. over in the bug to hook up dom storage to the TLD service dcamp used asciiHost, but maybe that's not going to work. I think UTF-8 is a mistake, the effectiveTLD list should be punycode (true ascii). Otherwise we have to keep editing the effective TLD list in accordance with our list of IDN-enabled domains, but the IDN domain list is really easy for users (or local partners) to edit

Load the following:
IDN-enabled:  http://gäb.de/   vs  http://xn--gb-via.de/  --> both gäb
Not IDN:      http://gäb.com/  vs  http://xn--gb-via.com/ --> both xn--gb-via

On the other hand for your purposes you do want to show the IDN name if the browser's going to show it, so nsIURI.host might be OK.

we can argue asciiHost vs host elsewhere, but either way you should do all your URI parsing through nsIURI rather than string operations.

	Dão Gottwald [:dao] Assignee
	Comment 37 • 18 years ago

no real UI change, hence no extension update for now

	jasir
	Comment 38 • 18 years ago

(In reply to comment #37)
> Created an attachment (id=252188) [details]
> patch 9, nsIURI instead of location
> 
> no real UI change, hence no extension update for now
> 

check out this extension (split browser)
it handles the location bar part pretty well.

https://addons.mozilla.org/firefox/4287/

	Dão Gottwald [:dao] Assignee
	Comment 39 • 18 years ago

split browser duplicates the location bar. seems unrelated to this bug.

	Dão Gottwald [:dao] Assignee
	Comment 40 • 18 years ago

Comment on attachment 252188 [details] [diff] [review]
patch 9, nsIURI instead of location

>+            if (valid && gBrowser.userTypedValue) {
>+              try {
>+                var uri2 = Components.classes["@mozilla.org/network/standard-url;1"].createInstance(Components.interfaces.nsIURI);
>+                uri2.spec = this._value;
>+                valid = (uri.spec == gURIFixup.createExposableURI(uri2).spec);
>+              } catch(e) {}
>+            }

I'm doing this in order to check if the location bar value matches currentURI. Is there a cleaner way to achieve this?
Options I see are:

 1. reset userTypedValue when submitting, so that I could replace the quoted
    chunk with |if (valid) valid = !gBrowser.userTypedValue|.

 2. don't use currentURI but always create a mew nsIURI object for the
    current location bar value.

 3. ignore userTypedValue in prettyView(), i.e. only show the maybe-typed
    value on mouseover or focus.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 41 • 18 years ago

I haven't really read the patch yet, so I don't know the answer to your question, but I just wanted to point out that you should never createInstance an nsIURI, unless you're implementing a protocol handler. The IOService has a newURI method that you should use, see http://developer.mozilla.org/en/docs/Common_Pitfalls#How_to_create_a_URI_object . There's also an nsIURI equals() method that you can use if you want to compare two nsIURI objects for equality (rather than comparing .spec), though I'm not sure whether it applies here.

	Dão Gottwald [:dao] Assignee
	Comment 42 • 18 years ago

(In reply to comment #41)
> you should never createInstance an nsIURI, unless you're implementing a
> protocol handler. The IOService has a newURI method that you should use

Thanks, I'll take care of that.

> There's also an nsIURI equals() method that you can use if you want to
> compare two nsIURI objects for equality (rather than comparing .spec), though
> I'm not sure whether it applies here.

I tried that first, didn't seem to work. Anyway, I want to avoid such a comparison.

	Dão Gottwald [:dao] Assignee
	Comment 43 • 18 years ago

kind of implements point 2 of comment 40 and uses IOService (comment 41)

	Daniel Veditz [:dveditz]
	Comment 44 • 18 years ago

(In reply to comment #36)
> That's a bit confusing. over in the bug to hook up dom storage to the TLD
> service dcamp used asciiHost, but maybe that's not going to work. I think UTF-8
> is a mistake, the effectiveTLD list should be punycode (true ascii). Otherwise
> we have to keep editing the effective TLD list in accordance with our list of
> IDN-enabled domains, but the IDN domain list is really easy for users (or local
> partners) to edit

Turns out the effectiveTLD service takes the UTF-8 list and normalizes it on load. Having the data pre-normalized might save a smidgen of time for any non-ascii domains but is not necessary, and having the .dat file more readable is a win.

You also don't have to give the service punycode, it'll take IDN and normalize it before comparing to the domain list. But the "number of characters" answer will be based on the normalized string so the answer might not match the string you have if yours is not already normalized. A bit confusing, all the more reason for the string-returning helper methods I proposed.

	Simon Bünzli
	Comment 45 • 18 years ago

A few things to think about, should this indeed be the way to go:

> Index: browser/app/profile/firefox.js
> +pref("browser.urlbar.decode", true);

Who'd want to toggle this pref? Since this is mostly for aesthetic reasons, we might be able to do without it and just always decode the URLs.

> +pref("browser.urlbar.strongDomain", true);
> +pref("browser.urlbar.separatorSpaces", 2);

These two prefs are purely presentational and should thus be replaced with CSS rules. Those users who actually care will still be able to adjust the appearance through userChrome.css.

> Index: browser/base/content/browser.js
> +var gDecodeURLs = false;

Don't use global variables, if you can do without. In this case, either get the values directly from the prefs where you assign them below - or even better, get the values in the constructor of the new binding. What clickSelectsAll does, doesn't really scale that nicely.

> Index: content/widgets/urlbar.xml
> +      <field name="alwaysPlainSchemes">["about","data"]</field>

Couldn't this be replaced with a check for whether a domain/host name is defined for a specific URI instead? Otherwise mailto: and possibly a few other protocols would also belong into this category.

> +              var uri = gBrowser.currentURI;

gBrowser (and gURIFixup) is Firefox- and not Toolkit-specific. You'll either have to do without it - or move the binding from toolkit to browser.

> +      <handler event="mouseover" phase="capturing"
> +               action="if (!this._plain) this.plainView();"/>

You should probably store the mouse-over state somewhere. Otherwise refreshing the page through F5/Ctrl+R will require a mouse-out before you can edit the address (there won't be another mouseover event even when the mouse is moved within the address bar).

	Dão Gottwald [:dao] Assignee
	Comment 46 • 18 years ago

(In reply to comment #45)
> > +pref("browser.urlbar.strongDomain", true);
> > +pref("browser.urlbar.separatorSpaces", 2);
> 
> These two prefs are purely presentational and should thus be replaced with CSS
> rules. Those users who actually care will still be able to adjust the
> appearance through userChrome.css.

But those style rules wouldn't apply to the content of the input element. Maybe I should put the nodes directly into the chrome and hide the input element. 

> > Index: content/widgets/urlbar.xml
> > +      <field name="alwaysPlainSchemes">["about","data"]</field>
> 
> Couldn't this be replaced with a check for whether a domain/host name is
> defined for a specific URI instead? Otherwise mailto: and possibly a few other
> protocols would also belong into this category.

file URIs don't have a host, but I do want to decode them and strip off file://
Hm. But I think in about:config, host is undefined, and in file:///foo, it's empty, so that could be a solution.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 47 • 18 years ago

The new urlbar binding should probably be added in /browser and not /toolkit, since it's pretty browser-specific and not really reusable for most other toolkit apps. That also avoids the dependency issues Simon mentions.

	Dão Gottwald [:dao] Assignee
	Comment 48 • 18 years ago

I thought it could be useful for apps like Songbird.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 49 • 18 years ago

I'm not sure that "could be useful" is significant enough to justify putting this into toolkit at the moment. It's easy to move into toolkit if there's a demonstrated need by other consumers, but it's nearly impossible to remove it from toolkit once it's been added for fear of breaking people who may depend on it, so I'd prefer defaulting to putting it in /browser.

	Daniel Veditz [:dveditz]
	Comment 50 • 18 years ago

What about SeaMonkey? They're trying hard to get their trunk version based on toolkit (but not /browser). How could they not want this? I guess we could ask, and put it in /browser if they show no interest.

	Benjamin Smedberg
	Comment 51 • 18 years ago

I agree this should be app-specific code. SM/songbird/whoever can reuse through copying if necessary.

	Dão Gottwald [:dao] Assignee
	Comment 52 • 18 years ago

- handled all points in comment 45
- moved to /browser, but removed the dependencies (global variables)
- added a fading effect

known issues:
- long URLs overflow the location bar (I'm not sure how to fix this)

	Dão Gottwald [:dao] Assignee
	Comment 53 • 18 years ago

http://design-noir.de/mozilla/locationbar2/0.5.xpi (slightly modified for Firefox 2)

	Dão Gottwald [:dao] Assignee
	Comment 54 • 18 years ago

just a small fix, extension updated as well (same URL)

Maybe fading on mouseover won't work. If you click really fast, the cursor (for some reason) will be put at the end of the location bar. I could speed it up (takes 110 milliseconds currently), but theoretically, it would always be possible to click faster.

	Simon Bünzli
	Comment 55 • 18 years ago

Comment on attachment 252456 [details] [diff] [review]
patch 12

Please wait for ui-review first, this isn't the time for a close-up review yet. And then rather ask a browser peer, I don't have much more to contribute.

	Dão Gottwald [:dao] Assignee
	Comment 56 • 18 years ago

Wasn't meant as a final review request.

	Rod Begbie
	Comment 57 • 18 years ago

With the 0.5.xpi on Firefox 2, I'm seeing the bug that if I focus on the address-bar by hitting ALT+D, URL autocompletion doesn't work, although it does if I focus on the address-bar by clicking.

	Dão Gottwald [:dao] Assignee
	Comment 58 • 18 years ago

some cleanup

added an extra element to the binding, because overflow:hidden interfered with -moz-box-align:center, which caused problems with many themes.

	Dão Gottwald [:dao] Assignee
	Comment 59 • 18 years ago

(In reply to comment #58)
> Created an attachment (id=252774) [details]
> patch 13

http://design-noir.de/mozilla/locationbar2/0.5.1.xpi

(In reply to comment #57)
> With the 0.5.xpi on Firefox 2, I'm seeing the bug that if I focus on the
> address-bar by hitting ALT+D, URL autocompletion doesn't work, although it does
> if I focus on the address-bar by clicking.

Yeah, but I don't know why. Any suggestions would be appreciated.

	Dão Gottwald [:dao] Assignee
	Comment 60 • 18 years ago

text-overflow:ellipsis would be nice, wouldn't it?

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 61 • 18 years ago

(In reply to comment #59)
 > (In reply to comment #57)
> > With the 0.5.xpi on Firefox 2, I'm seeing the bug that if I focus on the
> > address-bar by hitting ALT+D, URL autocompletion doesn't work, although it does
> > if I focus on the address-bar by clicking.
> 
> Yeah, but I don't know why. Any suggestions would be appreciated.

It also doesn't seem to be consistent. I see it sometimes, but not all.

	Dão Gottwald [:dao] Assignee
	Comment 62 • 18 years ago

- crops long URLs
- new pref: browser.urlbar.animateBlend
- more code cleanup

autocomplete is still broken.

http://design-noir.de/mozilla/locationbar2/0.5.2.xpi

	Dão Gottwald [:dao] Assignee
	Comment 63 • 18 years ago

autocomplete should be working again

http://design-noir.de/mozilla/locationbar2/0.5.3.xpi

	Dão Gottwald [:dao] Assignee
	Comment 64 • 18 years ago

color:graytext could be used, e.g. for the port.
Let me know if that's wanted.

	Dão Gottwald [:dao] Assignee
	Comment 65 • 18 years ago

Comment on attachment 253007 [details] [diff] [review]
patch 15

>+          try {
>+            // UTF-8
>+            path = decodeURIComponent(path);
>+          } catch(e) {
>+            // ISO Latin
>+            path = unescape(path);
>+          }

I'll probably remove the ISO Latin part, since it could be any encoding in reality.

	Gervase Markham [:gerv]
	Comment 66 • 18 years ago

I've been using Locationbar2, and think it has some really neat ideas. However, I think we also need some discussion about how to make it more usable, particularly in the selection scenario. I'm also concerned that making domain names bold can actually decrease readability - it certainly reduces the difference, on my copy of Firefox, between "i" and "l". 

However, I'm not sure that this bug is the best place to do feature development. Dao: would you care to suggest a better forum?

Gerv

	Dão Gottwald [:dao] Assignee
	Comment 67 • 18 years ago

Beltzner wrote he would potentially blog about this. Maybe it's also something for Mozilla Labs? They could point to a wiki page, which is probably the best place for collecting ideas.

	Dão Gottwald [:dao] Assignee
	Comment 68 • 18 years ago

I could also imagine using a smooth shadow for the domain (bug 10713).

	Gervase Markham [:gerv]
	Comment 69 • 18 years ago

Dao: we need to find some way of having the position of the letters not jump when you focus the control - otherwise it gets really annoying. 

This means that whatever highlighting we pick, it needs to stay when the control is focussed. Are there technical reasons why that is difficult?

Gerv

	Robert Kaiser
	Comment 70 • 18 years ago

I still feel a bit nervous about hiding the protocol. I don't think FTP/HTTP/HTTPS differences are unimportant enough to hide them (by default).

	Dão Gottwald [:dao] Assignee
	Comment 71 • 18 years ago

(In reply to comment #69)
> This means that whatever highlighting we pick, it needs to stay when the
> control is focussed. Are there technical reasons why that is difficult?

In the earlier versions, I was hacking the input field's editor object, with the result that the content wasn't fully editable anymore. I guess I could use Midas instead, but then styling the content wouldn't be as easy as it is now (i.e. through browser.css, userChrome.css etc.).

(In reply to comment #70)
> I still feel a bit nervous about hiding the protocol. I don't think
> FTP/HTTP/HTTPS differences are unimportant enough to hide them (by default).

FTP isn't hidden by default and secure sites are indicated in other (better) ways.

	Robert Kaiser
	Comment 72 • 18 years ago

Dão:
What are "better" ways? Coloring of the bar and an icon on a completely different part of the window are nice, but the latter is not too visible for many people and the coloring easily gets lost on other themes and/or low-color schemes. Additionally, there are lots of advisories out there that tell "make sure the display in the location bar starts with https://" - but maybe I'm just too nervous about it. I hope there's some pref for it we can default to off when maybe proting this to SeaMonkey browser one time - or we'll invent that ourselves ;-)

	Dão Gottwald [:dao] Assignee
	Comment 73 • 18 years ago

"make sure the display in the location bar starts with https://" isn't a good advice, since it doesn't mean that there's a valid certificate.

	Unknown W. Brackets
	Comment 74 • 18 years ago

(In reply to comment #73)
> "make sure the display in the location bar starts with https://" isn't a good
> advice, since it doesn't mean that there's a valid certificate.
> 

Bad advice doesn't mean uncommon advise.  Quite the opposite.  Just because sites and companies shouldn't tell people that doesn't mean they don't.

Example: go to eBay.  They say, I quote, right on the login page:

"Be sure the Web site address you see above starts with https://signin.ebay.com/"

My grandma really is going to listen to that before remembering some yellowish color that supposedly means something or other.  Is it really worth the evangelism to hide the protocol, which has been shown everywhere for years and no longer scares anyone (that I know of)?

Just my opinion.  I personally really like the idea of bolding the domain, but other than that it seems over the top.

-[Unknown]

	Caio Tiago Oliveira (asrail)
	Comment 75 • 18 years ago

The "low color" condition is very, very important.

One of the most important accessibility features is that we shouldn't rely on color alone to transmit information.

Some people can't see the difference between white and light yellow (there are a lot of other color combinations, I met people who see the world white, black, brown and purple).
The ones who have to use low-color schemes won't even notice it (both are gray here, same color, I wouldn't be able to know about the protocol except for the *little* icon at the very botom at the left of the screen).

In case of visual defficience, that little icon wouldn't make any difference, anyway.


In inverse high contrast I'm seing a little difference in the status bar (the border color), but that is not easily noticed. In high contrast the only difference is the border width (it's hard to guess by its size is it is a http or https site).


I'm strongly against hiding http, https or whatever.

	Caio Tiago Oliveira (asrail)
	Comment 76 • 18 years ago

Another great issue is that I wouldn't be able to copy'n'past links from SM into a lot of programs.

Some programs don't treat example.site.org as a link, while treat http://example.site.org (or http://whatever) as a link.
These programs/services usually treat www.site.org as a link, but not site.org or foo.site.org, because the lack of the space after the dot does not means it's a URL (it might be a typo).
Local URLs might consist of a word. So "localhost" is not a URL, while "http://localhost" is one.

I always use the http:// part while composing messages, so I'll be sure that it will be linkified for almos everyone.


I would be happy if I could copy links from the location bar with http:// before it.

Ah... no JS here, please, because it's good to have the option to choose if you will copy the http part or not without depending on a preference (I meant I should be able to copy only the "localhost" part to a message, if I'm chating with the sys-admin or...).

	Dão Gottwald [:dao] Assignee
	Comment 77 • 18 years ago

If you feel that the lock isn't good enough as an indicator, you should file a new bug for that. "https://" is not good enough, but contrary the the real "secure site" UI it won't enhance. Besides the fact that it's too cryptic, it can be a false friend. It's worthless as a visual metaphor.

(In reply to comment #74)
> Is it really worth the
> evangelism to hide the protocol, which has been shown everywhere for years and
> no longer scares anyone (that I know of)?

The lock has been there for years as well, across browsers. And at the end of the day, they really want to say "Be sure the Web site's domain name is ebay.com". Currently they can't do that, because users would have to parse the URL.

(In reply to comment #76)
Copy & paste is not an issue. Feel free to install Firefox and try the extension.

	Daniel Veditz [:dveditz]
	Comment 78 • 18 years ago

(In reply to comment #73)
> "make sure the display in the location bar starts with https://" isn't a good
> advice, since it doesn't mean that there's a valid certificate.

If an https page loaded then the certificate was valid (including cases where the user has said "I know better, this is valid"). We're planning to make the user-override case harder, btw.

	Gervase Markham [:gerv]
	Comment 79 • 18 years ago

I am for hiding the scheme. IMO, the differences between FTP and HTTP are incomprehensible to the average web user. In the HTTPS case, if we are telling people to look for the difference between the strings "http" and "https" in the UI in order to gain useful information, then our UI sucks rocks and we should fix it.

Removing the scheme allows us to do things like display an HTTPS site whose certificate has expired but is otherwise valid as if it was served over HTTP - which I think is a very good way of dealing with that particular error condition - without causing mixed signals.

As for copy and paste, we could (for example) prepend the scheme to a copied selection if that selection extends to the left edge of the URL bar.

Gerv

	Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com]
	Comment 80 • 18 years ago

(In reply to comment #77)
> If you feel that the lock isn't good enough as an indicator, you should file a
> new bug for that. "https://" is not good enough, but contrary the the real
> "secure site" UI it won't enhance. Besides the fact that it's too cryptic, it
> can be a false friend. It's worthless as a visual metaphor.
> 
> (In reply to comment #74)
> > Is it really worth the
> > evangelism to hide the protocol, which has been shown everywhere for years and
> > no longer scares anyone (that I know of)?
> 
> The lock has been there for years as well, across browsers. And at the end of
> the day, they really want to say "Be sure the Web site's domain name is
> ebay.com". Currently they can't do that, because users would have to parse the
> URL.

Maybe I'm just an idiot, but for *years* I wondered wtf an oil can was doing in the Netscape 3+ status bar: http://images.google.com/images?q=oil%20can

	Dão Gottwald [:dao] Assignee
	Comment 81 • 18 years ago

Comment on attachment 253007 [details] [diff] [review]
patch 15

working on a new patch

	Dão Gottwald [:dao] Assignee
	Comment 82 • 18 years ago

This has some limitations, mainly because I'm using <xul:editor/> that has to act like <html:input/>. Most notably, F6, right-click actions and auto-complete don't work yet. Would be nice if someone could take a look at the code and give me some hints.

	Dão Gottwald [:dao] Assignee
	Comment 83 • 18 years ago

How can <editor/> be made transparent?

	Gervase Markham [:gerv]
	Comment 84 • 18 years ago

You're asking in the wrong place :-) Try the newsgroups.

FWIW, I've had to disable Locationbar2 after installing your update. You broke Ctrl-L and focus, and it got very irritating very quickly. But please, do persist :-) Why not ask some of our core XUL hackers whether you are using the right approach?

Gerv

	Dão Gottwald [:dao] Assignee
	Comment 85 • 18 years ago

This doesn't really solve the problems. Just in case someone is willing to investigate, this might be a slightly better starting point.

	Dão Gottwald [:dao] Assignee
	Comment 86 • 18 years ago

Comment on attachment 253007 [details] [diff] [review]
patch 15

I've posted to mozilla.dev.tech.xul in order to get some hints. However, I'm not sure if this will lead anywhere; you might want to review that fairly stable version anyway.

	Dão Gottwald [:dao] Assignee
	Comment 87 • 18 years ago

a user comment from my website:

> is there any chance of making it act similar to the vista address bar.
> So while hovering on the address bar but not having clicked it, make it so u can
> select part of the URL to navigate to there?
> If you wanted to edit the url you would click on the white space at then end
> This would be handy from time to time.

Again, let me know if that's wanted. Maybe I'll give it a try anyway, although I don't know the "vista address bar".


btw, I didn't get a response in dev.tech.xul.

	Caio Tiago Oliveira (asrail)
	Comment 88 • 18 years ago

Instead of:
C:\Users\[user]\Documents\Links

you see:
[a picture] -> Documents -> Links

where those arrows are dropdown menus that list the contents of the folder.
When you mouse over the items they become clickable.

If you click the icon at the left or some white-space it changes to the traditional way (C:\Users...).

The user might be confused about where to click (or what to do) to be able to select the URL.

Well... I had a idea...

the users that don't like the mouse would still being able to select it with Control+L (that would trigger the very traditional way)...
the most users could get a "copy url" or "copy [protocol]:[the url]" and "copy [protocol]:[[optional prefix] domain]" to the clipboard, instead of selecting it and using Control+C or right-click and selecting "copy".

I may try to do a little HTML example (I don't know XUL very well) if someone desires.

VMWare lets me create movies... I could make a little one showing the way it works, although I don't like some things there.
Or I could make some screenshots.

	Dão Gottwald [:dao] Assignee
	Comment 89 • 18 years ago

Thanks, but I'm already implementing it. Looks good so far. Selecting all with Ctrl+L or when clicking the site icon already worked out of the box. I don't know how "copy url", "copy [protocol]:[the url]" etc. should work; maybe you can elaborate on that later.

I don't think we want a Vista rip-off, so you don't need to make a video either.

	Dão Gottwald [:dao] Assignee
	Comment 90 • 18 years ago

see comment 87

	Caio Tiago Oliveira (asrail)
	Comment 91 • 18 years ago

On Windows: when you click some link the URL bar switches to the normal mode-view, gots selected, then it loads the link. It's very quick, you might even don't notice depending on the time it takes to load the page, but the URL bar flashing is annoying.

On Linux: the above behaviour doesn't exist, but it won't switch to the normal mode-view while clicking with the mouse in any non-linkified portion of the URL-bar.


Just to mention: I've chat with Dão about to respect the "open link" settings and to allow to use middle or control+click and he told this could be left to a follow up bug.

	Dão Gottwald [:dao] Assignee
	Comment 92 • 18 years ago

(In reply to comment #91)
> On Windows: when you click some link the URL bar switches to the normal
> mode-view, gots selected, then it loads the link.

fixed

> Just to mention: I've chat with Dão about to respect the "open link" settings
> and to allow to use middle or control+click and he told this could be left to a
> follow up bug.

fixed

> On Linux: the above behaviour doesn't exist, but it won't switch to the normal
> mode-view while clicking with the mouse in any non-linkified portion of the
> URL-bar.

I still don't have access to Linux (right now) or OS X (at all) ...

	Dão Gottwald [:dao] Assignee
	Comment 93 • 18 years ago

just a quick update, right-click was broken.

	Dão Gottwald [:dao] Assignee
	Comment 94 • 18 years ago

(In reply to comment #93)
> just a quick update, right-click was broken.

and the left mouse button breaks the urlbar when "mousedown" fires but "click" doesn't, i.e. when moving the mouse away after "mousedown".

	Dão Gottwald [:dao] Assignee
	Comment 95 • 18 years ago

see last comment

	Caio Tiago Oliveira (asrail)
	Comment 96 • 18 years ago

Right click and middle click are OK on Linux, but what I told about Linux on comment 91 still valid.

I'll test to see if it's related to some accessibility thing later, or if it's general to Linux.

	Dão Gottwald [:dao] Assignee
	Comment 97 • 18 years ago

The old autocomplete bug is back. It works with Ctrl+L, but not when clicking into the urlbar. Apparently attachController() doesn't work when the input field's opacity is less than 1. It's annoying ...

	Dão Gottwald [:dao] Assignee
	Comment 99 • 18 years ago

I don't know what to do about the auto-complete bug. It works after removing this rule:

#urlbar:not([plain="true"]) .textbox-input-box {
  opacity: 0;
}

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 100 • 18 years ago

Why are you setting opacity to 0?

	Dão Gottwald [:dao] Assignee
	Comment 101 • 18 years ago

I'm using <stack> instead of <deck> in order to make the input field accessible even if it's not visible.

	Dão Gottwald [:dao] Assignee
	Comment 102 • 18 years ago

color: transparent; does the trick

	Dão Gottwald [:dao] Assignee
	Comment 103 • 18 years ago

(In reply to comment #92)
> (In reply to comment #91)
> > On Windows: when you click some link the URL bar switches to the normal
> > mode-view, gots selected, then it loads the link.
> 
> fixed

this regressed, probably because the selection is visible now (it wasn't when the opacity was 0).

	Dão Gottwald [:dao] Assignee
	Comment 104 • 18 years ago

added:

#urlbar:not([plain="true"]) {
  -moz-user-select: none;
}

I have a dream that one day I won't discover yet another problem immediately after hitting "Submit".

	Dão Gottwald [:dao] Assignee
	Comment 105 • 18 years ago

(In reply to comment #102)
> color: transparent; does the trick

only on trunk

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 106 • 18 years ago

Comment on attachment 255009 [details]
workaround for selection flashing

I know I've been withholding comment for a while. I had to wait on a conversation about where we want to feature this, and how we want to play with it. Basically, here's where we stand:

- I think this is a really interesting experiment, and when labs gets up and running, I want to feature it there to get more feedback from the world at large

- landing *all* of this on trunk without a clear definition of what the problems users currently have with the location bar seems inappropriate to me, and we're going to run afoul of reactionary arguments as to why this isn't actually helping things (more on that below)

- I'm not going to grant this ui-r until it's ready for inclusion on the trunk, so I'd suggest you hold off on the request until we've iterated around on this some more.

- we should probably track progress in this bug, still, but soon there will be a place at labs.mozilla.com where we can discuss design in a little more detail

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 107 • 18 years ago

Bah, I forgot to fill out the "below" part from comment 106 :)

LocationBar^2 originally was meant to fulfill the requests from the Firefox 3 brainstorming wiki (as mentioned in comment 0). It's done that, and more! The things requested on the brainstorming page were clear problems:

 - the location bar didn't display non-latin characters properly
 - the domain name was lost within the entire URL, showing the domain (or just the TLD and root domain) in bold would help reduce the effectiveness of homonym phishing attacks

These things are clear problems, and a patch that addresses just those things (but doesn't remove the protocol prefix or screw with direct edit, etc) would get a ui-r+ from me for trunk.

Since that original set of problems, we've gone off into some really interesting experiments, including:

 - stripping the somewhat hard to understand protocol prefix
 - separating the domain information from the path information
 - segmenting the path information and turning each segment into a link

These aren't directly linked to reported problems, and are creative solutions and enhancements. As experiments, I think we should encourage people to try them and comment, but until we figure out whether or not they're solving real user problems, they're not suitable for inclusion into the mainline product.

I hope this makes sense; I want to balance the Right Thing for the Product with Being Creative and Exploring New Ideas. :)

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 108 • 18 years ago

And my last comment of the evening will be on the experimental changes to the location bar with some UI feedback :)

= Vista-esque Location Bar =

(In reply to comment #89)
> Thanks, but I'm already implementing it. Looks good so far. Selecting all with
> Ctrl+L or when clicking the site icon already worked out of the box. I don't
> know how "copy url", "copy [protocol]:[the url]" etc. should work; maybe you
> can elaborate on that later.

Ugh, ick and ugh again. Removing the ability to directly edit the URI takes a *lot* of power away. I can no longer, for example, quickly replace part of the URI, or copy a segment of the URI, or do many of the actions that I'm used to doing. The reason this works in the Vista File Explorer is that they can make each segment a drop-down that's populated with the other directories at that level - so you can get all the power of manual edit while using the mouse. That isn't possible on the web, though, since we have no index of the entire directory structure of a site (though invoking history from that point would be interesting!)

Part of the success of this feature will be adding usefulness while not taking away usefulness, and I think this mod fails in that respect. For the first time in weeks I've been forced to disable the extension, as I'm simply unable to work as quickly with it.

Let's think about the problem we're trying to solve here, and then think about solutions for getting us there. Or figure out ways of adding the functionality without removing the old interactions. For example, if when you hover over a segment of the path a little (->) arrow appeared and clicking on that would use that segment as a link, otherwise click would select, drag would edit, etc, etc. 

= Stripping the protocol =

I think this is largely good, but we need to make sure that the semantics indicated by the protocol are preserved and visible to the user. For example, SSL semantics are also communicated by the colour of the location bar and the padlock icon. But what of the semantics of file:// and ftp://? The former seems important, the latter is debatable, but something should be added so that users can still get that information about their location context, especially in the case where they're browsing the local drive.

= Adding spaces between path segments =

This makes the URI harder to read, actually, since now every element (domain and path) has the same visual spacing. I think it's easier to segment domain from path with a single space between the two elements.

= Other things we could do =

We should think about how people use the location bar. Evidence shows that users do a lot of "type-in" URLs, and advanced users modify URIs to navigate sites they're familiar with. Other common actions are:

 - return to root of site
 - back / forward
 - next / previous page (increment/decrement some value in the URI)
 - go to a page within this domain that I've been to before (combination of direct-edit the URI and pull selection from history)
 - fix a typo in the URI
 - replace entire URI with a new URI (ie: navigate elsewhere on the web)

What can we do to support these specific use cases? Here are some ideas:

 - the domain element could have a widget that goes back to the root of the domain
 - right-click on any segment of the path could truncate the URI to that point and offer selections from history drop down
 - a single selection widget for clearing the location bar and jumping to a new point
 - right click on a numeric value could offer increment/decrement values expressed as "next" / "previous"

	Dão Gottwald [:dao] Assignee
	Comment 109 • 18 years ago

(In reply to comment #107)
> Since that original set of problems, we've gone off into some really
> interesting experiments, including:
> 
>  - stripping the somewhat hard to understand protocol prefix
>  - separating the domain information from the path information
>  - segmenting the path information and turning each segment into a link
> 
> These aren't directly linked to reported problems, and are creative solutions
> and enhancements.

The first and the second points are closely linked to "the domain name was lost within the entire URL".

> As experiments, I think we should encourage people to try
> them and comment, but until we figure out whether or not they're solving real
> user problems, they're not suitable for inclusion into the mainline product.
> 
> I hope this makes sense; I want to balance the Right Thing for the Product with
> Being Creative and Exploring New Ideas. :)

Sure; I'm looking forward to the Labs feedback.

(In reply to comment #108)
> Ugh, ick and ugh again. Removing the ability to directly edit the URI takes a
> *lot* of power away. I can no longer, for example, quickly replace part of the
> URI, or copy a segment of the URI, or do many of the actions that I'm used to
> doing. [...]
> Part of the success of this feature will be adding usefulness while not taking
> away usefulness, and I think this mod fails in that respect.

With version 0.5, I worked around this by switching to the plain view on mouseover. I can't do that anymore, because of the new interactivity of the formatted view. Maybe the selecting behaviour can be tweaked, but I don't think it will eventually be equal to the legacy textbox, unless somebody comes up with a totally new idea.

> = Stripping the protocol =
> 
> I think this is largely good, but we need to make sure that the semantics
> indicated by the protocol are preserved and visible to the user. For example,
> SSL semantics are also communicated by the colour of the location bar and the
> padlock icon. But what of the semantics of file:// and ftp://?

the visible difference between file and http is that there's no hostname for file. ftp isn't removed currently.

	Dão Gottwald [:dao] Assignee
	Comment 110 • 18 years ago

oh, and:

> Here are some ideas:
> 
>  - the domain element could have a widget that goes back to the root of the
> domain

that's already the case since the domain is a link.

	Dão Gottwald [:dao] Assignee
	Comment 111 • 18 years ago

addresses the following points:

> For example, if when you hover over a
> segment of the path a little (->) arrow appeared and clicking on that would use
> that segment as a link, otherwise click would select, drag would edit, etc,
> etc.

  Drag doesn't works, since the location bar would have to be in "plain" mode
  before mousedown fires.


> = Adding spaces between path segments =
> 
> This makes the URI harder to read, actually, since now every element (domain
> and path) has the same visual spacing. I think it's easier to segment domain
> from path with a single space between the two elements.

  I still gave the slashes inside of the path a padding of 1px.

>  - right-click on any segment of the path could truncate the URI to that point

  I think it's better to select all and provide a context menu for right-click.
  Hence I've used left-click, but not on the segments but on the slashes.


Firefox 2 isn't supported anymore (-> comment 105).

	Gervase Markham [:gerv]
	Comment 112 • 18 years ago

Dao: I agree with Mike; this is a great experiment, but we'll need to play around a lot to figure out exactly which of the changes we want to take on the trunk. And that would be made a lot easier if we could turn each one on and off individually, to try out different combinations.

Do you think you might be able to do a pref panel to allow that? I realise it's a non-trivial amount of work.

Gerv

	Mike Connor [:mconnor]
	Comment 113 • 18 years ago

I don't think that's useful at all.  About:config prefs _maybe_, but let's not encourage people to waste time on building UI for experimental features...

	Gervase Markham [:gerv]
	Comment 114 • 18 years ago

about:config prefs would be fine, if a pref panel is considered to be unnecessary effort. I care about the configurability much more than the mechanism (as long as it's not hand-editing CSS files in the extensions directory :-).

The prefs may or may not be part of any checkin which results from this experimentation: I just think it's useful to have them while we are deciding which of the changes we want to take.

Gerv

	Dão Gottwald [:dao] Assignee
	Comment 115 • 18 years ago

Actually, adding a UI would be trivial, as soon as the prefs are functional ;)
But adding prefs is relatively hard, as the code is not that modular.

	Mike Connor [:mconnor]
	Comment 116 • 18 years ago

1) We should be able to do something with favicon-like creatures to indicate a local file and/or ftp.  Neither really supports favicons so this should be universally possible.  I'll note that the treatment of ftp:// is ok as a fallback, but not as good as stripping the scheme entirely, since I think its not well understood or useful to present in addition to other things.

2) I actually find this behaviour really useful, since most of my URL editing is essentially going up a level or three.  Would like to be able to directly highlight chunks of the URL and change/edit them.  Maybe highlight the current text (using the same logic as we use in content to handle the selection of links), and convert that to a selection of the plaintext on mouseup?  Its slightly different when editing the middle of URLs, but without having a pretty comprehensive set of use cases to walk through in my head, but I think its a compromise that still allows "Up" navigation in the pseudo-breadcrumb approach here.

I think that most of the improvements we can make for users who don't understand URLs will impact power user manipulation of URLs to some extent.  Where we want to balance those needs is going to be fun.

	Gervase Markham [:gerv]
	Comment 117 • 18 years ago

Using favicons to indicate local files might run a risk that a website can pretend to be a local directory by spoofing the favicon. I don't know if that's a risk or not.

I think that the difference between ftp:// and http:// is now entirely irrelevant to the average Internet user, and would become even more so if we actually styled FTP listings nicely. So I second the proposal to get rid of ftp://.

As for selection, why don't we make the URL bar work like other text, where single click places the cursor, double-click selects a "word" (or URL component, in this case) and triple-click selects the whole thing?

Admittedly without evidence, I assert that the average user's interactions with the URL bar involves only typing something new to replace what's there already. Hacking bits off the end of URLs or modifying URL parameters is real power-user stuff, and I don't see that changing even if we make the divisions in a URL more obvious.

Gerv

	Dão Gottwald [:dao] Assignee
	Comment 118 • 18 years ago

regarding ftp see bug 294800. my proposal for that bug also includes a favicon: http://design-noir.de/bugzilla/ftp/ftp.xhtml

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 119 • 18 years ago

(In reply to comment #111 and others)
> the visible difference between file and http is that there's no hostname for
> file. ftp isn't removed currently.

Maybe we want to insert a "Your Computer" string at the root and a favicon to
represent it. Just to make it clear that's where the user is browsing.

> I still gave the slashes inside of the path a padding of 1px.

I don't think that's strictly neccessary, but I'm looking forward to seeing
what it's like. I can't install it on my copy of Minefield right now because it
isn't packaged to support 3.0a3pre :(

> But adding prefs is relatively hard, as the code is not that modular.

Yeah, I don't think we really need to do that, as long as we can get to a point
where there are various versions of the patch that people can try and comment
on with the different ideas exposed. Like, right now, I can install a version
from any point in the design by clicking on that XPI in the attachment list -
that's good enough for me, really. :)

(In reply to comment #116)
> I think that most of the improvements we can make for users who don't
> understand URLs will impact power user manipulation of URLs to some extent. 
> Where we want to balance those needs is going to be fun.

I agree, and so far what we have is a UI that replaces three types of
functionality:

 - selection (for copy/paste)
 - direct edit
 - quick invoke of typeahead find at a single segment of the URI

with:

 - ability to link directly to a portion of the URI, breadcrumb style

What mconnor suggests about using the same sort of logic as we use in the
content area for highlighting text in links makes sense to me. We should also
switch the mouse icon to a finger, since right now it makes no sense to be an
i-beam.

Again, I'd really love to see a patch for trunk that does the first two things
from comment 107, and then continued experimentation for the other things we're
all talking about.

	Caio Tiago Oliveira (asrail)
	Comment 120 • 18 years ago

(In reply to comment #119)
> (In reply to comment #111 and others)
> > the visible difference between file and http is that there's no hostname for
> > file. ftp isn't removed currently.
> 
> Maybe we want to insert a "Your Computer" string at the root and a favicon to
> represent it. Just to make it clear that's where the user is browsing.

That's a wonderfull idea.

> > I still gave the slashes inside of the path a padding of 1px.
> 
> I don't think that's strictly neccessary, but I'm looking forward to seeing
> what it's like. I can't install it on my copy of Minefield right now because it
> isn't packaged to support 3.0a3pre :(

The last one attachment installs on 3a3pre. It won't install on 3a2pre, indeed. It says it supports from 3a2 to 3a3 and I've tested with 3a3pre (from day 12th).

I don't think them look ugly, 1px is not a great ammount.

	Dão Gottwald [:dao] Assignee
	Comment 121 • 18 years ago

- clicking a segment selects it
- ftp:// hidden
- added a conditional hack for Gecko 1.8 (namely opacity:0 instead of color:transparent, which means that auto-complete remains broken with Firefox 2)

	Dão Gottwald [:dao] Assignee
	Comment 122 • 18 years ago

I'm starting to lose track ... we really need a wiki for all the suggestions.

(In reply to comment #116)
> We should also
> switch the mouse icon to a finger, since right now it makes no sense to be an
> i-beam.

The current logic is as follows:

- cursor:pointer if clicking will lead to a new page
- cursor:default if clicking will truncate but not submit the value
- cursor:text if the value won't be modified, but only selected

> Again, I'd really love to see a patch for trunk that does the first two things
> from comment 107, and then continued experimentation for the other things we're
> all talking about.

Like http://design-noir.de/mozilla/locationbar2/0.5.4.1.xpi? Or does that already go too far?

	Dão Gottwald [:dao] Assignee
	Comment 123 • 18 years ago

Here comes the "Your Computer" prefix for file URIs (no i18n yet).
I also did some refactoring and fixed several small bugs, and Gecko 1.8 compatibility should be better (my quirky detection failed occasionally).

	Caio Tiago Oliveira (asrail)
	Comment 124 • 18 years ago

Why can't I go to the root of my filesystem?
I think it would make sense to have that arrow with a shortcut to the root of the filesystem.

	Dão Gottwald [:dao] Assignee
	Comment 125 • 18 years ago

That would have to be platform-specific; Windows doesn't have a root directory.

	Caio Tiago Oliveira (asrail)
	Comment 126 • 18 years ago

I can confirm:
> On Linux: the above behaviour doesn't exist, but it won't switch to the normal
> mode-view while clicking with the mouse

on Ubuntu Dapper, a clean install. I also confirm after removing the package at-spi (I've though this one could be accessibility related).

Just one change:
sometimes (it's random) when I click some portion it becomes selected, but I still without the focus on the URL bar and the pretty view still appearing (the selection and the text of the plain URL override it).


PS: I'm almost get it working on SM done... after this I could do some more tests and even could try to fix it.

	Caio Tiago Oliveira (asrail)
	Comment 127 • 18 years ago

(In reply to comment #125)
> That would have to be platform-specific; Windows doesn't have a root directory.
> 

file://C:/foo/bar
against
file:///foo/bar

could have something like
   Your computer/root/foo/bar
when you have a slash at the start of the file URL.


> PS: I'm almost get it working on SM done... after this I could do some more
> tests and even could try to fix it.
On Suiterunner... I'm too lazy to make a install.js.

	Dão Gottwald [:dao] Assignee
	Comment 128 • 18 years ago

(In reply to comment #127)
> file://C:/foo/bar
> against
> file:///foo/bar
> 
> could have something like
>    Your computer/root/foo/bar
> when you have a slash at the start of the file URL.

nope, it's file:///C:/...

	Gervase Markham [:gerv]
	Comment 129 • 18 years ago

Those CCed on this bug may be interested in:
http://weblogs.mozillazine.org/gerv/archives/2007/02/location_bar_proposal.html
and associated newsgroup posting in mozilla.dev.apps.firefox.

Gerv

	Behnam Esfahbod [:zwnj]
	Comment 130 • 18 years ago

I was working on a similar extension, to remove the uri-schema from the address field, to make it able to be align:Right and dir:RTL.  In fact, IRI just forces to show the internationalize *URI* in LTR base direction.  So by removing the schema from the address field, we can make set the align/dir of the field based on UILocale or field's content (ie. making a list of RTL TLDs...).

Then another issue is how to show the protocol.  I used to add a dropdown-like widget to the address-bar (mine was before the site icon) with a localizable user-friendly text, like "Web" for http, and "File Transfer" for ftp.  I think we really need someway to show the protocol, as there are a lot of hosts which support both http and ftp on the same address, and have completely different content for each protocol.

Thanks for the good job. :)

	Dão Gottwald [:dao] Assignee
	Comment 131 • 18 years ago

Some users meant that 0.7 is actually less usable than 0.6. I understand the problem they have, but I don't want to go back. Instead I've replaced all the slashes by permanent, little Go buttons. New: middle-clicking a segment truncates the URL and opens the auto-complete popup.

Finally, all this should work with Firefox 2.

	Dão Gottwald [:dao] Assignee
	Comment 132 • 18 years ago

(In reply to comment #124)
> Why can't I go to the root of my filesystem?

should work now

	Dão Gottwald [:dao] Assignee
	Comment 133 • 18 years ago

This should fix the problems with Linux (thanks Asrail!). I've also updated the skin.

	Torben
	Comment 134 • 18 years ago

> I think that the difference between ftp:// and http:// is now entirely
> irrelevant to the average Internet user, and would become even more so if we
> actually styled FTP listings nicely. So I second the proposal to get rid of
> ftp://.

But how do I easily switch from ftp://ftp.example.com to http://ftp.example.com ? There are a lot of sites where these are _not_ the same.

	Dão Gottwald [:dao] Assignee
	Comment 135 • 18 years ago

(In reply to comment #134)
> But how do I easily switch from ftp://ftp.example.com to http://ftp.example.com
> ? There are a lot of sites where these are _not_ the same.

e.g. Ctrl+L, Home, Ctrl+Del, Enter

	Dão Gottwald [:dao] Assignee
	Comment 136 • 18 years ago

(In reply to comment #121)
> - clicking a segment selects it

I have to take care of clickSelectsAll=false

	Dão Gottwald [:dao] Assignee
	Comment 137 • 18 years ago

see previous comment

	Nickolay_Ponomarev
	Comment 138 • 18 years ago

Double-clicking to select parts of the URL on windows may not work properly now that the contents of the URL bar is changed (formatting stripped) on click. (This applies to the URL parameters only, like ?id=XXX on bugzilla, since to select other parts of the URL, it's enough to single click it.

Great job otherwise.

	Jason Barnabe (np)
	Comment 139 • 18 years ago

Can we drop the trailing triangle when we're at the root of the domain?

	Dão Gottwald [:dao] Assignee
	Comment 140 • 18 years ago

(In reply to comment #139)
> Can we drop the trailing triangle when we're at the root of the domain?

Technically, yes:

.textbox-presentation-prePath:not([can-submit="true"]) > .segment-submit {
  display: none;
}

	Dão Gottwald [:dao] Assignee
	Comment 141 • 18 years ago

As a result of Gerv's proposal and the related discussion in mozilla.dev.apps.firefox, this version does:

  1. remove the path segments' arrows
  2. remove the "Your Computer" label for file:// URIs
  3. display HDD letters as the domain for Windows file URIs
  4. drop the emphasis for IDN domains

I've also revised the mouse actions:

> left                          | select segment
> ------------------------------|-----------------------------------------
> Ctrl/Cmd + left,              | truncate URL after segment
> middle                        |
> ------------------------------|-----------------------------------------
> Alt/Option + left             | navigate to truncated URL
> ------------------------------|-----------------------------------------
> Alt/Option + Ctrl/Cmd + left, | open truncated URL in new tab
> Alt/Option + middle           |
> ------------------------------|-----------------------------------------
> Alt/Option + Shift + left     | open truncated URL in new window
> ------------------------------|-----------------------------------------
> Shift + left                  | select all (Win)
> ------------------------------|-----------------------------------------
> right                         | select all (Win), open the context menu


Still, not all of this seems to work with Linux, and I don't have a clue if it does with OS X. If you can, please test it on Windows in order to get a sane impression of the concept.

	Caio Tiago Oliveira (asrail)
	Comment 142 • 18 years ago

Alt + left will, by default on most Linux window managers, move the window, so the event is not propagated to Firefox. I believe changing the default shortcut for this would help.

Alt + Control + left works, for instance, but Alt + Shift + left arrives to the same issue as above.


"select all" works on Linux, as well as selecting a token when clicking it if browser.urlbar.clickSelectsAll is true at the startup (it would be good to change this behaviour, but it's the same without the extension, so it's a FX issue, not yours). I do believe it's the same for Windows, only the default that changes.

I think the only real issue with Linux is that with a right click it opens the chrome context menu, instead of the URL bar one (I got "navigation toolbar | bookmarks toolbar | customize" instead of "undo | cut | copy | ...").
Take a look.

	Dão Gottwald [:dao] Assignee
	Comment 143 • 18 years ago

(In reply to comment #142)
> Alt + left will, by default on most Linux window managers, move the window, so
> the event is not propagated to Firefox. I believe changing the default shortcut
> for this would help.

I'll try Shift. I wanted to avoid that, since Shift is a link target modifier.

	Dão Gottwald [:dao] Assignee
	Comment 144 • 18 years ago

Shift instead of Alt, i.e.:

 left                     | select segment
--------------------------|-----------------------------------------
 Ctrl/Cmd + left,         | truncate URL after segment and open
 middle                   | auto-complete popup
--------------------------|-----------------------------------------
 Shift + left             | navigate to truncated URL
--------------------------|-----------------------------------------
 Shift + Ctrl/Cmd + left, | open truncated URL in new tab
 Shift + middle           |
--------------------------|-----------------------------------------
 right                    | select all (Win), open the context menu

(In reply to comment #142)
> I think the only real issue with Linux is that with a right click it opens the
> chrome context menu

fixed

(In reply to comment #139)
> Can we drop the trailing triangle when we're at the root of the domain?

done

	Dão Gottwald [:dao] Assignee
	Comment 145 • 18 years ago

beltzner, gerv: I think you will like this one.
There are many little changes, but to sum it up: things don't move anymore. On the downside, this means that the protocol isn't hidden (would produce an odd gap otherwise) but only greyed out. Shift still linkifies segments.

	Behnam Esfahbod [:zwnj]
	Comment 146 • 18 years ago

Dão, can't we have hostname bold when entering/editing the url?

Also, there's a funny bug.
- Add boolean key "network.IDN.whitelist.ir" to your prefs
- Open this link: http://xn--mgbbgcw7khi.xn--mgba3a4f16a.ir/
- After page loaded, select the url and press Enter again
- Select the url and press Enter again

You will see punycode and unicode strings periodically!

	Behnam Esfahbod [:zwnj]
	Comment 147 • 18 years ago

And I see URL-Encoded UTF characters instead of unicode characters again, under //xn--mgbbgcw7khi.xn--mgba3a4f16a.ir/ [1], but there's no problem with Persian Wikipedia [2].

[1] http://ثبت‌دامنه.ایران.ir/سلام   (This page doesn't exist)
[2] http://fa.wikipedia.org/wiki/صفحهٔ_اصلی

So I assume there's no pref for this one, and something is related to TLD and/or Host.

	Dão Gottwald [:dao] Assignee
	Comment 148 • 18 years ago

(In reply to comment #146)
> Dão, can't we have hostname bold when entering/editing the url?

That will make it less usable again, unless we use a fixed-width font.

> Also, there's a funny bug.
> - Add boolean key "network.IDN.whitelist.ir" to your prefs
> - Open this link: http://xn--mgbbgcw7khi.xn--mgba3a4f16a.ir/
> - After page loaded, select the url and press Enter again
> - Select the url and press Enter again
> 
> You will see punycode and unicode strings periodically!

Funny enough, I see this without the extension.

	Gervase Markham [:gerv]
	Comment 149 • 18 years ago

Dao: you may want to wait until the dust settles on the discussion before doing too much more work. I am not really sure where it'll end up. I've already changed my mind about a couple of things based on what people have said.

I'll certainly try out your new one. But please, be aware that lots of things could change in the future :-) I don't want you to put a load of work in and then feel messed around when they do.

Gerv

	Behnam Esfahbod [:zwnj]
	Comment 150 • 18 years ago

As you can see, when the direction of end-part of hostname, and start of the path are both RTL, current solution breaks IRI.

Trying to fix this problem, you may get a layout problem, which smontagu is working on, which some tags break (bidi) direction runs.

CC: smontagu

	Behnam Esfahbod [:zwnj]
	Comment 151 • 18 years ago

smontagu, would you please take a look at last attachment.

	Dão Gottwald [:dao] Assignee
	Comment 152 • 18 years ago

This contains a fix for IDNs (effective tld service takes them with punycode only).

(In reply to comment #145)
> things don't move anymore. On
> the downside, this means that the protocol isn't hidden (would produce an odd
> gap otherwise)

I worked around this by moving the favicon into that gap. Unideal, but still the best solution that came to my mind. The favicon can be dragged when pressing Shift.

(In reply to comment #149)
> Dao: you may want to wait until the dust settles on the discussion before doing
> too much more work. I am not really sure where it'll end up.

Me neither. It's just, as soon as an idea pops up that is potentially good and probably implementable, I feel the need to try it ;-)

	Mike Connor [:mconnor]
	Comment 153 • 18 years ago

I haven't played with 0.8.1 yet, but I think 0.7.3.1 is the closest I've found to being ok with landing this.  0.8 felt like it was throwing away a lot of useful things...

	Dão Gottwald [:dao] Assignee
	Comment 155 • 18 years ago

http://xs412.xs.to/xs412/07081/locationbar.png

Is red an option? I was against it, because it's usually a security-related color. But if all domains are red, it probably doesn't matter. On the other hand, the security-metaphor could be utilized, i.e. a white-list for trusted (green) domains could be added.

	Dão Gottwald [:dao] Assignee
	Comment 156 • 18 years ago

(In reply to comment #155)
> i.e. a white-list for trusted (green) domains could be added.

Note that this list could be auto-generated. For example, sites that you have bookmarked or saved passwords for.

	Caio Tiago Oliveira (asrail)
	Comment 157 • 18 years ago

I told some things about relying on color alone for indicating the difference between http/https and Gerv said it is outside the scope of this extension.
But this color would be something added by you, so... please, don't rely on colors alone (see comment 75 as most of that apply to using only color to emphasize the domain).

	Dão Gottwald [:dao] Assignee
	Comment 158 • 18 years ago

- blue text color for domains
- bringing back the gap between domain and path
- spaces re-encoded to %20


(In reply to comment #157)
> please, don't rely on colors alone

Still, a color is better than nothing. So far I don't see alternatives that wouldn't decrease usability.

	Jason Barnabe (np)
	Comment 159 • 18 years ago

Some observations:

I like this much better than 0.7.2 (respecting clickSelectsAll, not having the triangle buttons).

Can you make it so that the URL only changes "views" after pausing on the location bar? I'm finding it somewhat distracting that it's doing its thing when I'm on my way to the search bar.

When you open a new blank tab and start entering a URL, it shouldn't leave a space for a favicon.

Can you make it so that the pieces of text that don't change position don't turn gray for a split-second when you mouse over them?

The text-only view seems to not have enough padding on the left, though this just might be me not being used to it.

	Dão Gottwald [:dao] Assignee
	Comment 160 • 18 years ago

(In reply to comment #159)
> Can you make it so that the URL only changes "views" after pausing on the
> location bar? I'm finding it somewhat distracting that it's doing its thing
> when I'm on my way to the search bar.

A delay would mean that the user could click before the input field appears, making it impossible to drag-select.

> Can you make it so that the pieces of text that don't change position don't
> turn gray for a split-second when you mouse over them?

I don't understand what you're seeing there.

> When you open a new blank tab and start entering a URL, it shouldn't leave a
> space for a favicon.
> [...]
> The text-only view seems to not have enough padding on the left, though this
> just might be me not being used to it.

Any space or padding that you add to the editable view has to be added to the formatted view as well.

	Jason Barnabe (np)
	Comment 161 • 18 years ago

(In reply to comment #160)
> > Can you make it so that the pieces of text that don't change position don't
> > turn gray for a split-second when you mouse over them?
> 
> I don't understand what you're seeing there.

Sorry, I meant "when you mouse out". There's a transition that turns the text gray (transparent?) when you go from editable view to formatted view. Since the path part of the URL doesn't change between the views, it'd be better if it didn't transition.

> > When you open a new blank tab and start entering a URL, it shouldn't leave a
> > space for a favicon.
> > [...]
> > The text-only view seems to not have enough padding on the left, though this
> > just might be me not being used to it.
> 
> Any space or padding that you add to the editable view has to be added to the
> formatted view as well.

I understand. But regarding the first, it appears as though new blank tabs have the padding of formatted view even when you're typing in the URL.

	Dão Gottwald [:dao] Assignee
	Comment 162 • 18 years ago

(In reply to comment #161)
> Sorry, I meant "when you mouse out". There's a transition that turns the text
> gray (transparent?) when you go from editable view to formatted view. Since the
> path part of the URL doesn't change between the views, it'd be better if it
> didn't transition.

Yes, transparency has a hand in this. The text field's opacity (x) continuously decreases, while the formatted view's opacity (1-x) increases. This works as expected here -- no gray for the parts that keep their position.

> I understand. But regarding the first, it appears as though new blank tabs have
> the padding of formatted view even when you're typing in the URL.

That's because the urlbar doesn't have the "hidden protocol" state there. For example, open chrome://locationbar2/skin/urlbar.css. The input field needs padding for being aligned with the formatted URL. Of course, that doesn't make sense if there's no formatted view anyway. I'll fix that.

	Dão Gottwald [:dao] Assignee
	Comment 163 • 18 years ago

-> favicon better reachable (without Shift)

(In reply to comment #161)
> it appears as though new blank tabs have
> the padding of formatted view even when you're typing in the URL.

fixed

	Dão Gottwald [:dao] Assignee
	Comment 164 • 18 years ago

- entering the Location bar over the favicon also linkifies segments
  (no need to press Shift)
- more solid behaviour when pressing Shift

	Kim Sullivan
	Comment 165 • 18 years ago

The 0.8.2.1 version breaks some themes - I know it's still a prototype, so I'd like to ask if it's an issue, or if it's not something to worry about yet.

	Dão Gottwald [:dao] Assignee
	Comment 166 • 18 years ago

I wouldn't worry about it now as I wouldn't worry about it later. Themes will certainly have to be updated for future Firefox releases -- with or without this bug fixed.

	Dão Gottwald [:dao] Assignee
	Comment 167 • 18 years ago

has some predefined styles to play with

	Dão Gottwald [:dao] Assignee
	Comment 168 • 18 years ago

Btw, most of these optional styles cause known problems. So far they're not really there to give new ideas a try but to prove that they don't work. However, the infrastructure for pluggable stylesheets is there. That could be useful for Labs.

	Dão Gottwald [:dao] Assignee
	Comment 169 • 18 years ago

significant updates:

- moving the mouse over the Location bar from above linkifies segments
- link targets appear in the status bar
- query string and fragment gray by default (not sure if this is good)
- last directory/file linkified as well (useful for duplicating a tab)
- preferences and pluggable stylesheets updated

	Aleksei Perepelkin [:chaos]
	Comment 170 • 18 years ago

How about to switch to (or from) linkified location bar by pressing key, when location bar is already hovered?

Also it should be nice if location bar default state will be linkified and to edit it we need to right- or middle-clicking on it :)

	Dão Gottwald [:dao] Assignee
	Comment 171 • 18 years ago

(In reply to comment #170)
> How about to switch to (or from) linkified location bar by pressing key, when
> location bar is already hovered?

Ctrl is used for copy/paste and Shift for creating selection ranges.

> Also it should be nice if location bar default state will be linkified and to
> edit it we need to right- or middle-clicking on it :)

Drag-selecting doesn't work then. (It could be an option anyway, as mconnor said he would be ok with 0.7.3.1.)

	Dão Gottwald [:dao] Assignee
	Comment 172 • 18 years ago

Some summarized thoughts on domain emphasis:

Even beyond accessibility, mixing a certain color (blue) with system colors (-moz-field, -moz-fieldtext) is obviously problematic. It also makes the whole appearance a bit noisy; likewise I'd avoid "highlight" and "highlightText" (attachment 253336 [details], bottom).

Let me repeat that bold is likely a dead end. It's not an option for complex scripts (you could underline IDNs, but still ...), and it's apparently impossible to keep in visual sync with the editable view.

So far the last alternative I see is to use graytext for subdomains. You can mimic this with recent Lb² releases: uncheck domain colors, then visit a site with a "www." subdomain.

	Dão Gottwald [:dao] Assignee
	Comment 173 • 18 years ago

As you may have noticed, I'm not adding comments for each release anymore. For those who are interested in the small development steps, here's a feed:
http://en.design-noir.de/mozilla/locationbar2/?versions-feed

If you have suggestions like comment 170, feel free add a comment to my site:
http://en.design-noir.de/mozilla/locationbar2/

This way we should be able to focus the bug on what's most relevant.

	Aleksei Perepelkin [:chaos]
	Comment 174 • 18 years ago

>> How about to switch to (or from) linkified location bar by pressing key, when
>> location bar is already hovered?
>
>Ctrl is used for copy/paste and Shift for creating selection ranges.

I'm not talking about when it is already in focus, but hovered.

>Drag-selecting doesn't work then. (It could be an option anyway, as mconnor
said he would be ok with 0.7.3.1.)

What is drag-selecting? I don't understand the problem.

Is locationbar² to make a revloution in browser's location bars or what? ;-)

Making it configurable will make it more useful.

I think that hovering from top or from bottom to get different behavior is not handy!

	Jeff Walden [:Waldo]
	Comment 175 • 18 years ago

(In reply to comment #173)
> As you may have noticed, I'm not adding comments for each release anymore.
> [...] This way we should be able to focus the bug on what's most relevant.

Honestly, at this point I don't think that's worthwhile, except as a way of not making people read about every little change you make (which does have some merit, incidentally ;-) ).  This bug has a solid 3-4 screens of attachments, it's up to 175 comments, and when the time comes for real reviews *nobody's* going to want to have to wade through it, so you'll get a new bug filed then anyway.

	Dão Gottwald [:dao] Assignee
	Comment 176 • 18 years ago

(In reply to comment #174)
> >> How about to switch to (or from) linkified location bar by pressing key, when
> >> location bar is already hovered?
> >
> >Ctrl is used for copy/paste and Shift for creating selection ranges.
> 
> I'm not talking about when it is already in focus, but hovered.

Umm, yes, I guess that would be possible.
There's of course one problem with these keys: They are used to determine where the URL will be loaded. Hence this isn't a solid replacement for the mouse behavior that you dislike.

> Is locationbar² to make a revloution in browser's location bars or what? ;-)
> 
> Making it configurable will make it more useful.

The default setup is what we have to wrestle with; many users don't really configure anything. If linkification of segments turns out to be a usability problem, one way or another, we shouldn't escape into options, leaving it to the user to make tradeoffs, but just leave this feature out. I suppose most users don't need it. Eventually, a revised Location bar will be extensible again.

	Dão Gottwald [:dao] Assignee
	Comment 177 • 18 years ago

http://en.design-noir.de/mozilla/locationbar2/0.8.6.xpi

new prefs: "Gray Subdomains" (comment 172), "Only linkify when pressing Ctrl/Meta or Shift" (somehow comment 176)

(In reply to comment #170)
> How about to switch to (or from) linkified location bar by pressing key, when
> location bar is already hovered?

implemented

	Modex
	Comment 178 • 18 years ago

If you add "Gray Subdomains" can you make linkify only for domains (without of subdomain)?

	Gervase Markham [:gerv]
	Comment 179 • 18 years ago

Dao: I can't get "Gray Subdomains" to be enabled. Even if I remove all colours, it's still greyed out. Any idea what's going on?

Some further thoughts:

- I've written up my latest ideas here:
http://wiki.mozilla.org/Firefox3/Location_Bar

- I love the way that, if you have "placeholder for hidden protocols" and "margin after the host" both checked, only the host moves around and not the rest of the URL. That's so much better. In this case, can you even up the gap on both sides (a tiny nitpick :-)?

- You seem to be greying out the slashes between path components. This seems to me to be exactly the opposite of what you want as an anti-spoofing measure, where separators are very important. Can you make them bold instead?

- Can we have an option to highlight Effective TLD + N, where N is configurable? If not, can we have an option to either do +1 or +2, the two possibilities in question? The non-highlighted part would move around as necessary with the rest of the domain, but would not pick up the colour.

- Any chance of making the highlight colour configurable (#RRGGBB)? I agree bold may not work but, if it doesn't, we need to pick the actual colour carefully.

- I don't know how much control you have over selection behaviour, but can you make it behave like my proposal linked above (section 2.7)?

- Can you outline here your current algorithm for when and how you decode complex URLs in the unfocussed state?

- I like the idea of making the query string a bit lighter, but I think you may have gone too far. Can you darken it a touch more? We need to remember people with poor eyesight.

Thanks :-)

Gerv

	Dão Gottwald [:dao] Assignee
	Comment 180 • 18 years ago

(In reply to comment #179)
> Dao: I can't get "Gray Subdomains" to be enabled. Even if I remove all colours,
> it's still greyed out. Any idea what's going on?

Did you use a trunk build? Subdomain detection requires nsEffectiveTLDService, which isn't available (yet) for 1.8.

> - I've written up my latest ideas here:
> http://wiki.mozilla.org/Firefox3/Location_Bar

I'm presumably familiar with most of this already, since I followed the discussion in the newsgroups closely. Anyway, thanks for creating that page. I will take a close look at it.

> - I love the way that, if you have "placeholder for hidden protocols" and
> "margin after the host" both checked, only the host moves around and not the
> rest of the URL. That's so much better. In this case, can you even up the gap
> on both sides (a tiny nitpick :-)?

The gaps will grow if you chose to show the favicon always or never (instead of sometimes.)

> - You seem to be greying out the slashes between path components. This seems to
> me to be exactly the opposite of what you want as an anti-spoofing measure,
> where separators are very important. Can you make them bold instead?

I'm quite sure even a bold slash demands more space, causing the path to move on hover; I'll give it a try, though.

> - Can we have an option to highlight Effective TLD + N, where N is
> configurable? If not, can we have an option to either do +1 or +2, the two
> possibilities in question? The non-highlighted part would move around as
> necessary with the rest of the domain, but would not pick up the colour.

What's the point of TLD + 2? TLD + 1 is the registered domain that you should trust or not trust. You cannot trust yourbank.xxx.com, and users should look at xxx.com first to get that.

> - Any chance of making the highlight colour configurable (#RRGGBB)? I agree
> bold may not work but, if it doesn't, we need to pick the actual colour
> carefully.

I don't think you'll find a color that works significantly better than the blue. Most important, any color can be too close to the default fore- or background color of a random OS theme. So even if it's easy, I wouldn't want to add such a pref; I doubt a non-system color will be the final solution.

> - I don't know how much control you have over selection behaviour, but can you
> make it behave like my proposal linked above (section 2.7)?

I don't have control over the selection behaviour currently, because I hardly touch the input field. But I have that on my radar.

> - Can you outline here your current algorithm for when and how you decode
> complex URLs in the unfocussed state?

decoreURI -- a JS function that decodes Unicode URIs (only) -- is used for both states. However, if you copy the entire value, spaces will be encoded again, which is important for text-based communication with link detection (e-mail, IM, forums ...).

> - I like the idea of making the query string a bit lighter, but I think you may
> have gone too far. Can you darken it a touch more? We need to remember people
> with poor eyesight.

That's "graytext", a system color. I did try to use transparency once, but the result was poor (bug 355972?).

	Gervase Markham [:gerv]
	Comment 181 • 18 years ago

(In reply to comment #180)
> Did you use a trunk build? Subdomain detection requires nsEffectiveTLDService,
> which isn't available (yet) for 1.8.

Oops - that's the problem.

> The gaps will grow if you chose to show the favicon always or never (instead of
> sometimes.)

Sure. I have it set to never, like the proposal. It would be nice for the gap to be even on both sides in this case.

> > - You seem to be greying out the slashes between path components. This seems to
> > me to be exactly the opposite of what you want as an anti-spoofing measure,
> > where separators are very important. Can you make them bold instead?
> 
> I'm quite sure even a bold slash demands more space, causing the path to move
> on hover; I'll give it a try, though.

Give it a try. Otherwise, keep the slashes as #000 black and lighten the path components a bit.

Alternatively, we could have them (and other separators like ?, & and #) bold in both the textbox form and the non-focussed form. I seem to remember you made that possible at one point. But perhaps that had technical issues.

> What's the point of TLD + 2? TLD + 1 is the registered domain that you should
> trust or not trust. You cannot trust yourbank.xxx.com, and users should look at
> xxx.com first to get that.

On the other hand, there are advantages to TLD + 2. For example, consider "gerv.blogspot.com". Also, it means the "www.foo.com", which is a common case, has the www highlighted, which looks nicer.

I agree there are also downsides. The jury is still out on this one - which is why I want it configurable, so we can test both cases.

> > - Any chance of making the highlight colour configurable (#RRGGBB)? I agree
> > bold may not work but, if it doesn't, we need to pick the actual colour
> > carefully.
> 
> I don't think you'll find a color that works significantly better than the
> blue. 

How about a darker blue, for example? I don't know if I'll find a better colour until I can try some :-)

> Most important, any color can be too close to the default fore- or
> background color of a random OS theme. So even if it's easy, I wouldn't want to
> add such a pref; I doubt a non-system color will be the final solution.

Does the Firefox theme we ship by default respect OS colours, then? If not, then this isn't a problem and we won't be using a system colour.

> > - Can you outline here your current algorithm for when and how you decode
> > complex URLs in the unfocussed state?
> 
> decoreURI -- a JS function that decodes Unicode URIs (only) -- is used for both
> states. However, if you copy the entire value, spaces will be encoded again,
> which is important for text-based communication with link detection (e-mail,
> IM, forums ...).

It is allowed to encode spaces as a "+" in URLs, isn't it, as well as %20? Perhaps the textbox version could keep everything encoded, but have spaces as +. That way, there's less jumping between versions than if you had to replace space with %20.

Gerv

	Robert Kaiser
	Comment 182 • 18 years ago

Gerv:
All our default themes try to use OS-style theming, including colors, as much as possible, including the toolkit/Firefox default *stripe theme set.
So if the OS uses dark-blue background on textboxes (with light-yellow text or so), we still should display the location bar properly...

	Gervase Markham [:gerv]
	Comment 183 • 18 years ago

So what system color name will get you the current red, blue and green that the prefs offer? Or are they not system colours?

Is there a list of system colour names and suggested uses somewhere?

Gerv

	Dão Gottwald [:dao] Assignee
	Comment 184 • 18 years ago

(In reply to comment #181)
> > The gaps will grow if you chose to show the favicon always or never (instead of
> > sometimes.)
> 
> Sure. I have it set to never, like the proposal. It would be nice for the gap
> to be even on both sides in this case.

I see. That's probably not possible with pure XUL+CSS, at least given how the host is positioned currently. But some scripting should do it.

> Give it a try. Otherwise, keep the slashes as #000 black and lighten the path
> components a bit.

I suspect you would find it too faint again.

> Alternatively, we could have them (and other separators like ?, & and #) bold
> in both the textbox form and the non-focussed form. I seem to remember you made
> that possible at one point. But perhaps that had technical issues.

It had. Maybe somebody but me could do that.

> > You cannot trust yourbank.xxx.com, and users should look at
> > xxx.com first to get that.
> 
> On the other hand, there are advantages to TLD + 2. For example, consider
> "gerv.blogspot.com".

And what about gerv.blogs.mozilla.org? The line that you want to draw is actually independent from the TLD length; it varies from site to site. Plus, the intended security win is negated with TLD + N (N > 1). So the question imho is: TLD + 1 or no splitting at all?

> How about a darker blue, for example? I don't know if I'll find a better colour
> until I can try some :-)

Btw, until I implement this (I'm not really convinced yet), you can also use the DOM Inspector to add style="color:foo" to the domain node.

> It is allowed to encode spaces as a "+" in URLs, isn't it, as well as %20?
> Perhaps the textbox version could keep everything encoded, but have spaces as
> +.

It depends on the server to decode "+" into a space. E.g. see http://php.net/rawurldecode vs. http://php.net/urldecode.

> That way, there's less jumping between versions than if you had to replace
> space with %20.

There's no jumping currently, as both visible representations of the address are decoded. 20% will only be in your clipboard.

(In reply to comment #183)
> So what system color name will get you the current red, blue and green that the
> prefs offer? Or are they not system colours?

the latter

> Is there a list of system colour names and suggested uses somewhere?

http://www.w3.org/TR/CSS21/ui.html#system-colors

One of the ThreeD* values could be an option, but I'm not sure if they can be used safely as text colors, with -moz-field in the background.

	Dão Gottwald [:dao] Assignee
	Comment 185 • 18 years ago

filed bug 373011

	Gervase Markham [:gerv]
	Comment 186 • 18 years ago

> The line that you want to draw is
> actually independent from the TLD length; it varies from site to site. Plus,
> the intended security win is negated with TLD + N (N > 1).

It's not independent; saying so is the old computer programmers, "0, 1 or an infinite number" fallacy. There are far more gerv.blogspot.com-type sites than there are gerv.blogs.subsubdomain.subdomain.example.com sites. And the intended security win is not entirely negated for N > 1; it decreases as N increases. Like I said, we want to try out N = 2 and see if it's an overall improvement. And we can't do that unless you at least make it an option :-) "Let's try it" is not the same as "We're almost certainly going to do this."

> There's no jumping currently, as both visible representations of the address
> are decoded. 20% will only be in your clipboard.

The problem with that is, as someone commented in the newsgroup, it does mean that you can have URLs which look in the URL bar like you can see all of them but in fact you cannot. I don't think URLs should ever display with spaces in for this reason.

> It depends on the server to decode "+" into a space.

Well, all URL decoding depends on the server! I'm not sure what you mean here.

As for system colours, the list presented at the URL doesn't have enough different options. Which is fair enough; it's not supposed to be an exhaustive list. We use colours elsewhere in the interface which aren't system colours (e.g. the icons, or 'HTTPS yellow'). Yes, we'd need a way to make sure the text was always readable (perhaps by comparing to the background colour) but if we had that, then I don't see why we can't choose a colour.

Gerv

	Caio Tiago Oliveira (asrail)
	Comment 187 • 18 years ago

(In reply to comment #186)
> 
> > There's no jumping currently, as both visible representations of the address
> > are decoded. 20% will only be in your clipboard.
> 
> The problem with that is, as someone commented in the newsgroup, it does mean
> that you can have URLs which look in the URL bar like you can see all of them
> but in fact you cannot. I don't think URLs should ever display with spaces in
> for this reason.

Using the X11 clipboard also would fail.

> > It depends on the server to decode "+" into a space.
> 
> Well, all URL decoding depends on the server! I'm not sure what you mean
> here.

Some servers don't decode + as a space, so %20 is not strictly equals to +.
Wikipedia uses a _ as an alias to a space, but it decodes %20 but not +.

> As for system colours, the list presented at the URL doesn't have enough
> different options. Which is fair enough; it's not supposed to be an exhaustive
> list. We use colours elsewhere in the interface which aren't system colours
> (e.g. the icons, or 'HTTPS yellow'). Yes, we'd need a way to make sure the text
> was always readable (perhaps by comparing to the background colour) but if we
> had that, then I don't see why we can't choose a colour.
> 

Some people don't distinguish blue from black, some people don't distinguish blue from yellow.
So, for some people, a blue domain would fade into the background or not to be distinguishable from the rest of the text in the URL:
http://en.wikipedia.org/wiki/Color_blindness

Some people don't distinguish any color at all, only contrasts, so doesn't there is a perfect way for everyone and customizing is worth.

	Dão Gottwald [:dao] Assignee
	Comment 188 • 18 years ago

(In reply to comment #186)
> It's not independent; saying so is the old computer programmers, "0, 1 or an
> infinite number" fallacy. There are far more gerv.blogspot.com-type sites than
> there are gerv.blogs.subsubdomain.subdomain.example.com sites.

So there will be a billion happy first-level-subdomain gervs (no offence, but that includes phishers :-), and a million sad second-level-subdomain gervs. While I don't understand why someone should be sad because his whatever-level subdomain is grey (like all others), I do understand that the second-level subdomain doesn't want to be second class when a first-level subdomain is first class, for reasons that are beyond my horizon. Which leads to the mentioned conclusion: downgrade all subdomains or just leave it.

Mind that the whole idea behind splitting and highlighting was to reduce spoofing risk. Are there more yourbank.xxx.com than yourbank.xxx.yyy.com-type sites? At least, there /will/ be more once the first subdomain is highlighted.

> And the intended
> security win is not entirely negated for N > 1; it decreases as N increases.

It isn't harder or even less popular to create yourbank.xxx.com instead of yourbank.xxx.yyy.com. Thus I stick to it, the security win is lost if you highlight the first subdomain; it can even be negative, if you promote the highlighting as an anti-spoofing helper -- which was the original idea.

> Like I said, we want to try out N = 2 and see if it's an overall improvement.
> And we can't do that unless you at least make it an option :-) "Let's try it"
> is not the same as "We're almost certainly going to do this."

FWIW, it's "we're most certainly not going to do this." I really don't see the logics behind N = 2. I mean, not at all. Having your personal subdomain highlighted is nicer? Okay. Having www highlighted is nicer? Question of taste. Are these weighty arguments against N = 1? I strongly doubt that. If they were, we shouldn't split anywhere but say goodbye to whole idea (see above). I don't feel the need to try it, because the relevant facts are assessable.

> > There's no jumping currently, as both visible representations of the address
> > are decoded. 20% will only be in your clipboard.
> 
> The problem with that is, as someone commented in the newsgroup, it does mean
> that you can have URLs which look in the URL bar like you can see all of them
> but in fact you cannot. I don't think URLs should ever display with spaces in
> for this reason.

In the next release, I'm introducing a tooltip for URLs that exceed the text box.
We could also try to display · for spaces in the formatted view. I wonder if that dot has the width of a space for all fonts.

> > It depends on the server to decode "+" into a space.
> 
> Well, all URL decoding depends on the server! I'm not sure what you mean here.

I mean that %20 is the standard. If you type a space in the address bar, it will be submitted as %20. %20 is also covered by either of the PHP functions that I referred to.

> As for system colours, the list presented at the URL doesn't have enough
> different options. Which is fair enough; it's not supposed to be an exhaustive
> list. We use colours elsewhere in the interface which aren't system colours
> (e.g. the icons, or 'HTTPS yellow').

The HTTPS colors (yellow and black, both hard-coded) are completely independent of the system, so the problem doesn't exist there.

> Yes, we'd need a way to make sure the text
> was always readable (perhaps by comparing to the background colour) but if we
> had that, then I don't see why we can't choose a colour.

If we had that, I would agree. But that should be a core functionality so that we can use |color: -moz-foo|. I wouldn't want to do the analysis of the background in the binding, because that could break themes that use a background image. If we stick to CSS, theme authors can just replace -moz-foo by their preferred colors.

	Dão Gottwald [:dao] Assignee
	Comment 189 • 18 years ago

(In reply to comment #188)
> > > There's no jumping currently, as both visible representations of the address
> > > are decoded. 20% will only be in your clipboard.
> > 
> > The problem with that is, as someone commented in the newsgroup, it does mean
> > that you can have URLs which look in the URL bar like you can see all of them
> > but in fact you cannot. I don't think URLs should ever display with spaces in
> > for this reason.
> 
> In the next release, I'm introducing a tooltip for URLs that exceed the text
> box.
> We could also try to display · for spaces in the formatted view. I wonder if
> that dot has the width of a space for all fonts.

In addition to the tooltip, 0.9 displays an ellipsis at the end.