User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 There are a few extensions, which offers this functionality, but maybe it should be a default feature (has to be discussed), that every domain-name in the URL bar will be highlighted to focus attention to it and makes it easier to see, whether it's the right page. Reproducible: Always Steps to Reproduce: 1. 2. 3.

This was tried in alpha versions of Firefox 3 and failed see https://bugzilla.mozilla.org/show_bug.cgi?id=388135#c5 - The alternatives implemented were bug 383183 and bug 329292 (an intro ? icon for the Larry dialog is bug 426835) This is likely a dupe of bug 366797

Since bug 366797 covered many things and that part of bug 366797 was reverted, it doesn't make sense to mark this as a dup.

this is a new implementation and highlights the full domain

Comment on attachment 336757 [details] [diff] [review] patch Can't hurt to get a code review, although it still needs to be figured out if this bug is wanted.

Comment on attachment 336757 [details] [diff] [review] patch Gah, we have *got* to make this selection stuff dynamically extensible

Comment on attachment 336757 [details] [diff] [review] patch >+ this.controller.repaintSelection(this.selectionType); This line is unneeded overhead, consider it removed.

removed repaintSelection

Just to clarify, is this for all domains or just the non-SSL domains? There is already an about:config pref for SSL, see http://kb.mozillazine.org/Browser.identity.ssl_domain_display

(In reply to comment #8) > Just to clarify, is this for all domains or just the non-SSL domains? For all.

I am willing for this feature to be added due to other browsers such as chrome and IE8 offering. Some people might like it and some wont so it should be an option in any case.

I agree, I think that this would be a useful feature but to make it as an option.

Voted for this. Would be nice to have but with a on/off switch in about:config. Just wondering but somewhere in the firefox 3.0 dev cycly the Locationbar2 mod was build into firefox. Did that part got deleted at some point in the 3.0 dev cycle since it's not in there and not in 3.5 If it was deleted could someone explain why? Thanx, Mark

(In reply to comment #11) > I am willing for this feature to be added due to other browsers such as chrome > and IE8 offering. > > Some people might like it and some wont so it should be an option in any case. Google Chrome highlights with sub-domains. On the other hand IE8 highlights only the domain-name. Highlighting only the domain-name will be better.

(In reply to comment #16) > Google Chrome highlights with sub-domains. On the other hand IE8 highlights > only the domain-name. Highlighting only the domain-name will be better. Agreed. The current Firefox 4 mockup by Stephen Horlander also highlights the domain name more prominently than the sub-domain(s). https://wiki.mozilla.org/Firefox/4.0_Windows_Theme_Mockups Jono also wrote about some users not understanding urls: http://jonoscript.wordpress.com/2010/02/18/some-people-cant-read-urls/ URL hierarchy is confusing since the most important part is sandwiched in the middle (sub.domains.IMPORTANT.TLD/path/...) Implementing Horlander's mockup might mitigate this.

Should this be a papercut bug? https://bugzilla.mozilla.org/show_bug.cgi?id=565510

Does this patch highlight the full domain name or does it match the mockups from comment 17?

(In reply to comment #19) > does it match the mockups from comment 17? The patch is two years old. Besides, I don't see mockups related to this on the page linked to in comment 17, probably because that comment is four months old.

Ooops, I didn't notice the datestamps :) Well, do we still want this as part of the Firefox 4 theme revamp?

this is the two year old patch updated to tip, untested

(In reply to comment #21) > Ooops, I didn't notice the datestamps :) Well, do we still want this as part of > the Firefox 4 theme revamp? This particular bug doesn't have much to do with the theme, it just highlights the domain like IE and Chrome do it.

(In reply to comment #20) > Besides, I don't see mockups related to this on the page linked to > in comment 17, probably because that comment is four months old. Previous mockups had something like this¹ which I think is what we still want. [1] http://blog.stephenhorlander.com/2009/12/21/windows-themeui-update/

(In reply to comment #24) > (In reply to comment #20) > > Besides, I don't see mockups related to this on the page linked to > > in comment 17, probably because that comment is four months old. > > Previous mockups had something like this¹ which I think is what we still want. > > [1] http://blog.stephenhorlander.com/2009/12/21/windows-themeui-update/ This has unclear interaction implications as it's using boldface. For this reason the selection controller (used by the current patch) only allows changing the foreground and background color, AFAIK. Chrome and IE probably have similar implementations because of this.

Let's wait for Shorlander to tell us what it should look like.

I've been working with shorlander on this so I can fill in the missing information while he's off on vacation. Here is a quick mockup of the identity block in the normal (non-sll or ev) state: http://people.mozilla.com/~faaborg/files/20100625-tabsOnTop/tabsOnTop.png This still needs to sent out for more public comment, but the overall idea is that the identity block and the URL should not contain redundant information. When you select in the path, the entire area converts to text (maintaining position, the subdomain and domain will probably already be part of the string, just white text on white background and lower in the z-order).

Faaborg: thanks - feels like there should be a new bug for that, as that's a much different highlight. Is there a UI spec page for this? We don't have a lot more time for public comment before feature freeze on Sept 1

>Is there a UI spec page for this? it's only half complete, I got pulled off of it last week when Sync and Account Manager needed updated mockups. I'm hoping to have complete mockups and a blog post up mid next week.

Is it possible to get the current patch here reviewed and into a beta? This change is very conservative compared to the mockups, other browsers and also the changes that were initially committed in the Fx 3 cycle. As far as I can tell, this sets the protocol:// (and any optional login credentials) to grey and anything from the first slash (inclusive) after the domain onwards to grey, leaving the domain black. There is no eTLD or subdomain analysis. Any more cosmetic changes could come afterwards, and any radical changes like the "identity block" Alex hinted at could be looked at for Firefox 4.1. If it was up to me here's what I would arrange to be done: 1. Post a screenshot of what the patch does. 2. ui-review it 3. Form a new, more conservative, doable-for-Fx-4 mockup and policy 4. Get the patch reviewed (at a guess, Gavin and roc and maybe a security check from jonath) 5. Write a test for various URL possibilities and expected outcomes 6. Check it in 7. (All the other things that have to be done for Fx4) 8. Release 9. Beers all round One thing I have noticed from looking through the patch is that a port number will be highlighted as part of the domain (http://www.delorie.com:81/some/url.txt for example would be www.delorie.com:81). This doesn't happen in my test of Chromium on Linux (5.0.375.127). My guess is that it shouldn't be highlighted.

OK, it seems like bug 587901 is for the Identity Block to display the domain name (fixed for Fx 4) and bug 588270 is for having the Identity Block as part of the displayed URL (post Fx 4). Is that correct? Is it correct to say that if bug 588270 is fixed, this bug will be WONTFIX (in it's current form of displaying URLs similar to how IE and Chrome do)?

I think there is problem with the sites; www.nic.tr and www.tsk.tr I think that they should be highlighted as nic.tr and tsk.tr However Firefox highlights them as www.nic.tr and www.tsk.tr

(In reply to comment #32) > I think there is problem with the sites; www.nic.tr and www.tsk.tr > I think that they should be highlighted as nic.tr and tsk.tr > However Firefox highlights them as www.nic.tr and www.tsk.tr see bug 571433

updated to tip

Dão, do you think that the last part of comment 30 should be fixed? > One thing I have noticed from looking through the patch is that a port number > will be highlighted as part of the domain > (http://www.delorie.com:81/some/url.txt for example would be > www.delorie.com:81). This doesn't happen in my test of Chromium on Linux > (5.0.375.127). My guess is that it shouldn't be highlighted. If so, then I think altering the regex as follows would be enough. - ^((?:http|https|ftp):\/\/(?:[^\/]+@)?)([^\/]+) + ^((?:http|https|ftp):\/\/(?:[^\/]+@)?)([^:\/]+)

I don't really see why the port should be excluded, but as you say it's a trivial modification, so if somebody could tell me why it's the right thing to do I can make that change.

This is on top of the patch in bug 597769.

Dao, in most cases users don't care about port, since in 99% it's http or https (and in case it's https and you type http - in 99% that won't cause a problem for you). Ftp sites usually can be easily distinguished by their outlook. And the port itself is not so important, for a user when he needs to pronounce the address of the page.

(In reply to comment #39) > Dao, in most cases users don't care about port, since in 99% it's http or https And in that 99.9+% there is no port at all to highlight. Even if the link or user specified :80 or :443 when navigating our URL canonicalization will remove the standard ports when we display it. > And the port itself is not so important, for a user when he needs to pronounce > the address of the page. When there is a port it is critical that a user "pronounce" it, otherwise they will end up on the wrong site. It's extremely unusual to have an explicit port and we should highlight that fact.

(In reply to comment #40) > When there is a port it is critical that a user "pronounce" it, otherwise they > will end up on the wrong site. It's extremely unusual to have an explicit port > and we should highlight that fact. Yeah, agreed. It might be a bit less visually pleasing, but it's definitely part of what domain you are on, and example.com:8080 is not the same as example.com.

(In reply to comment #41) The main point of this is that a user is not misled about the domain they are on. The subdomain will rightly be greyed out so, e.g. paypal.com.evil.net, doesn't fool the user. Hilighting the port would be useless/misleading -- this is supposed to be indicating the domain name only, not the specific host/port (which would be specific to the sub-domain anyway)

I'm not into the technical aspects of implementing this, but can't help but notice that no-one has pointed out that the previous two mockups linked above are both awful: neither shows the protocol ('http://') section of the uri. How has it been decided that the protocol is of no importance? Furthermore, the second example (tabsontop) is awful also because it wastes horizontal space. There is zero spare horizontal space in the uri field. There is none to waste. For proof, see my previous two sentences. You need to fit the protocol into the uri field. Thirdly, the tabsontop mockup link is awful because it is ugly, and what is the function supposed to be of a dropdown list for the domain name? Have there been numerous feature requests from users who want to visit exactly the same uri but with the domain name different? I think not. All that is needed is a background colour against the domain name section of the uri, inline (not quite the way my current 3.5 browser shows the domain name PLUS the full uri on https sites, wasting precious horizontal space in the uri field). Nothing else needed, just some kind of background colour highlighting, and only on the domain name section. No?

What's the target milestone for this?

(In reply to comment #44) > What's the target milestone for this? When it's done. It's not making Firefox 4 if that is what you are asking.

(In reply to comment #43) > I'm not into the technical aspects of implementing this, but can't help but > notice that no-one has pointed out that the previous two mockups linked above > are both awful: neither shows the protocol ('http://') section of the uri. > > How has it been decided that the protocol is of no importance? > > Furthermore, the second example (tabsontop) is awful also because it wastes > horizontal space. There is zero spare horizontal space in the uri field. There > is none to waste. For proof, see my previous two sentences. You need to fit the > protocol into the uri field. > > Thirdly, the tabsontop mockup link is awful because it is ugly, and what is the > function supposed to be of a dropdown list for the domain name? Have there been > numerous feature requests from users who want to visit exactly the same uri but > with the domain name different? I think not. > > All that is needed is a background colour against the domain name section of > the uri, inline (not quite the way my current 3.5 browser shows the domain name > PLUS the full uri on https sites, wasting precious horizontal space in the uri > field). > > Nothing else needed, just some kind of background colour highlighting, and only > on the domain name section. No? I concur -you presented your case very well (keep it simple). This is a very important security enhancement that is well over due. Security bugs, and/or enhancements should always take priority over anything else. IE has had this security feature for quite some time. Firefox should not continue to postpone this security enhancement, because it may give users the erroneous perception that security enhancements are not at the top of developers priority list, which I know nothing can be further from the truth.

Opera: http://my.opera.com/desktopteam/blog/2010/11/17/new-and-improved

(In reply to comment #43) > I'm not into the technical aspects of implementing this, but can't help but > notice that no-one has pointed out that the previous two mockups linked above > are both awful: neither shows the protocol ('http://') section of the uri. > How has it been decided that the protocol is of no importance? Most sites use the http protocol, https/ftp would assumably be still displayed in some form.

Will this bug land in Fx4? I see [target-betaN], but no hard- or softblocker-tag?

(In reply to comment #49) > Will this bug land in Fx4? I see [target-betaN], but no hard- or > softblocker-tag? No, it didn't get blocking status, and won't make 4.0. the [target-betaN] is unrelated to the blocker status, sorry about the confusion there.

builds will be available at http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/dgottwald@mozilla.com-4c4ad78fd4a6

Comment on attachment 522352 [details] [diff] [review] updated to tip granting just based on described functionality

What is the status of this feature? I thought this should land together with the new identity block?

This feature it's a must, it is nice to have add-ons (locationbar2) but there are some browser features that must be added by default and this is one of them.

Comment on attachment 529440 [details] [diff] [review] hidden pref and test added (r=roc, ui-r=faaborg) Review of attachment 529440 [details] [diff] [review]: I'd like to see one additional test that checks that the hidden preference does in fact turn this feature off. r=sdwilsh with comments addressed. ::: browser/base/content/test/browser_urlHighlight.js @@ +1,1 @@ +function testVal(aExpected, aExplicitValue) { You don't ever call this with aExplicitValue, so you can remove it. @@ +44,5 @@ + testVal("mailto:admin@mozilla.org"); + testVal("gopher://mozilla.org/"); + testVal("about:config"); + + Services.prefs.clearUserPref("browser.urlbar.formatting.enabled"); You should do this in a function added with registerCleanupFunction in case something happens to throw (unlikely with the current test, but tests change, and I'd rather future-proof it). ::: browser/base/content/urlbarBindings.xml @@ +202,5 @@ + baseDomain = Services.eTLD.getBaseDomainFromHost(domain); + } catch (e) {} + let segments = function (s) s.replace(/[^.]*/g, "").length + 1; + let subSegments = segments(domain) - segments(baseDomain); + let subDomain = domain.match(new RegExp("(?:[^.]*\.){" + subSegments + "}"))[0]; I'm so very glad you wrote a test for this :)

Thanks for rendering the url in the address bar unreadable (except for the domain part, of course).

Shall I file a new bug for my issue in comment #58?

The change looks very good on me: http://i.imgur.com/xRByz.jpg thanks for check-in.

(In reply to comment #60) > Shall I file a new bug for my issue in comment #58? yep

On my system the highlighting is not dark enough. I can hardly tell the difference between the highlighted text and the rest of the URL. Is there a pref to make it darker? Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110502 Firefox/6.0a1 - Build ID: 20110503014006

This is not done in a very 'themable' way. The 'GetURLSecondaryColor' just gets the color value of 'graytext', why is that? Why not using a span with class?

(In reply to comment #63) > On my system the highlighting is not dark enough. I can hardly tell the > difference between the highlighted text and the rest of the URL. Is there a > pref to make it darker? only browser.urlbar.formatting.enabled (In reply to comment #64) > This is not done in a very 'themable' way. The 'GetURLSecondaryColor' just gets > the color value of 'graytext', why is that? Ideally bug 256773 would solve this. > Why not using a span with class? This would require a more invasive implementation and didn't perform very well last time we tried it.

Good enough for me, how do I enable this feature in Firefox 4.0.1?

> how do I enable this feature in Firefox 4.0.1? Firefox 4.0.1 doesn't have this feature, but you can install an add-on such as <https://addons.mozilla.org/firefox/addon/locationbar%C2%B2/>.

The builds link is dead, any new link? Thanks

(In reply to comment #66) > Good enough for me, how do I enable this feature in Firefox 4.0.1? You can also try Smart Text, which offers additional features besides domain highlighting. https://addons.mozilla.org/en-US/firefox/addon/smart-text/

Thanks! On a related note, every time I am going to add a new add-on Firefox displays a "Software Installation" dialog box with the following caption: "Install add-ons only from authors you trust. Malicious software can damage your computer or violate your privacy." How does one established a trusted author? How does some established a trusted add-on?

Firefox 4.0.1 new redesign of the Site Identity Button with its inconspicuous multi-colored status background is in my opinion a very bad idea. Did we not learn anything from the old multi-colored Homeland Security Advisory System? The reason the multi-colored Homeland Security Advisory System was recently changed, is because no one could remember what it meant. What happened to KISS (Keep It Simple Stupid), Don’t Make Me Think (great Best Seller read on Web Design/Usability), we need to bring the Padlock icon (Example: Green Padlock icon = Secure, and Grayed-Out Padlock icon = Unsecure) back as soon as possible, and place it where it belongs before Site Identity Button. Everyone that has every used a browser is already familiar with the Padlock icon/symbol, and knows what it means, and everyone who has ever used a computer knows what a green vs grayed-out icon means –no explanation, retraining, remembering, etc... required.

Jerry, your comment is off-topic, since has nothing to do with this bug. It's also in the wrong place, since this is a resolved bug. Please move your thoughts to a more appropriate place, like your own bug report or mozilla.dev.usability newsgroup.

Sorry, I pasted it on the wrong browser tab...

Post number 70 is related though.

please STOP posting in here! I already removed myself from the CC but i somehow keep getting mails from this bug. QUIT IT! It's implemented and heavily oftopic the last dozen posts.

Back to topic. Highlight for UK domains like foo.co.uk, foo.police.uk and even foo.bar.sch.uk works fine, but it does not work for foo.parliament.uk

there is problem with tsk.tr domains i think. there are totally 35 domainnames that end with tsk.tr (source: https://www.nic.tr/index.php?USRACTN=YEARSTAT#tsk.tr ) but it always highlights the tsk.tr part such as in http://www.kkk.tsk.tr/ Where is the related bug?

(In reply to comment #77) > there is problem with tsk.tr domains i think. there are totally 35 domainnames > that end with tsk.tr (source: > https://www.nic.tr/index.php?USRACTN=YEARSTAT#tsk.tr ) but it always highlights > the tsk.tr part such as in http://www.kkk.tsk.tr/ > > Where is the related bug? That was supposed to have been fixed in bug 606922. Maybe the ! exception rule doesn't work ok ? That might explain comment 76 too. Please don't comment here anymore, file new bugs or (better) look if it has been filed before.

This bug is marked "RESOLVED FIXED" but I am not seeing a highlighted URL in my nightly builds[1]. On which branch has this fix landed? Is it OFF by default? [1] Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110430 Firefox/6.0a1 ID:20110430030554

(In reply to comment #79) > This bug is marked "RESOLVED FIXED" but I am not seeing a highlighted URL in my > nightly builds[1]. On which branch has this fix landed? Is it OFF by default? > > [1] Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110430 Firefox/6.0a1 > ID:20110430030554 you are not using the latest nightly build. you have to update.

You're right! I didn't realize my updates were lagging so far behind (I've been using the release build a lot lately because Battlefield Play4Free doesn't work with the nightly builds).

Verified on: Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110505 Firefox/6.0a1

Sorry if my status Whiteboard note caused confusion or concern. The note was *not* an indication that the release team has evaluated this feature and determined that it needs to be backed out. The Whiteboard note is just a record of why the release team is tracking this issue in the first place -- that it's a new feature that hasn't yet fully proved itself for this release. I've udpated the Whiteboard to say "[tracking+ because this is new feature in 6]" which should hopefully be less alarming.

Dao, it looks like all the dependencies here are fully cleared. Do you know of anything else that would get in the way of this feature shipping in 6? (Note, my question in this closed bug is to Dao. If anyone other than Dao or one of the module peers or reviewers responds, I'm not going to be happy.)

(In reply to comment #84) > Dao, it looks like all the dependencies here are fully cleared. Yep. > Do you know of anything else that would get in the way of this feature > shipping in 6? Nope.

Is [sg:want] still needed?

We usually don't remove [sg:want] from bugs just because they're fixed, if that's what you're asking.