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.

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.

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.

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 -*-

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.

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

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.

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

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"?

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

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

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

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

> - 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()

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

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

Oh, and Ald+D / F6 are broken.

Alt+D

Comment on attachment 251787 [details] [diff] [review] WIP 4 (had typo) I suppose that will perform better with the mousedown event.

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

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

moving from themes to xul.css

diff was broken

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.

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.

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!

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

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

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

no behaviour change

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?

see comment 32

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

was flawed

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

no real UI change, hence no extension update for now

(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/

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

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.

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.

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

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

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

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

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

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.

I thought it could be useful for apps like Songbird.

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.

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.

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

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

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

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.

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.

Wasn't meant as a final review request.

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.

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

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

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

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

- 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

autocomplete should be working again http://design-noir.de/mozilla/locationbar2/0.5.3.xpi

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

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.

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

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.

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

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

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

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

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 ;-)

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

(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]

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.

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

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.

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

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

(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

Comment on attachment 253007 [details] [diff] [review] patch 15 working on a new patch

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.

How can <editor/> be made transparent?

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

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

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.

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.

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.

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.

see comment 87

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.

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

just a quick update, right-click was broken.

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

see last comment

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.

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

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; }

Why are you setting opacity to 0?

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

color: transparent; does the trick

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

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

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

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

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

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"

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

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.

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

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

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

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

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.

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.

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

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

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

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

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

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?

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

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.

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

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.

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

(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:/...

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

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

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.

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

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

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

(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

(In reply to comment #121) > - clicking a segment selects it I have to take care of clickSelectsAll=false

see previous comment

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.

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

(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; }

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.

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.

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

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

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.

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!

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.

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

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

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

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

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 ;-)

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

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.

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

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

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

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.

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

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

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

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

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

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.

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.

has some predefined styles to play with

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.

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

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

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

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.

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.

>> 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!

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

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

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

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

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

(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?).

(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

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

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

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

filed bug 373011

> 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

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

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

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