This bug covers the final visual styling of the personal/site identity block for all platforms. Changes include: -removing the favicon (visually redundant with the favicon in the tab). Drag operations can be completed with the tab. -adding a down arrow to indicate that it contains additional information -inactive and active area for particular notifications (will be used by geolocation and account manager)

This is just for reference, Stephen will post final graphics to be used.

Just one word: sexi! The more GFX things I see the more I like it.

Updated identity block mockup.

(In reply to comment #0) > -removing the favicon (visually redundant with the favicon in the tab). Drag > operations can be completed with the tab. Dragging a tab will detach it in most cases... See also bug 578929 comment 17

Comment on attachment 466515 [details] Rough mockup for icon reference Is this attachment obsolete? The new image only shows the site identity with no icons for popup notification anchors.

Those aspects of the mockup are not obsolete (but the lack of redundancy is being covered in bug 588270)

>Dragging a tab will detach it in most cases... Let's make the identity block dragable so that we can continue to support operations like placing a link on the desktop.

(In reply to comment #7) > >Dragging a tab will detach it in most cases... > > Let's make the identity block dragable so that we can continue to support > operations like placing a link on the desktop. Do people attempt to drag links to desktops? I remember creating bug 564798, where I stated that File (Firefox button) save, should save a link, rather than download the page, I think that would be more useful that introducing a draggable that will go underused. Especially such an important area which can be the difference between some people having things like bank accounts phished and not.

We don't have data on how often people do it, however since this was a common way to create bookmarks with IE6 (they use Windows Explorer as the equivalent to our library window), I would expect the behavior to be used by some of the people coming over from IE (especially those who are continuing to access their bookmarks from My Documents > My Favorites, with them now launching in Firefox)

Stephen, why domain's name is displayed separetaly? The previous mockup from Alex shows domain's name in indentity box and rets of the adress as normal text. Why duplicating it?

Comment on attachment 466515 [details] Rough mockup for icon reference filed bug 590439 on the notification icons

Comment on attachment 468985 [details] [diff] [review] patch >+++ b/browser/base/content/browser.xul >- <stack id="page-proxy-stack" >- onclick="PageProxyClickHandler(event);"> >- <image id="urlbar-throbber" busy="false"/> >- <image id="page-proxy-favicon" validate="never" I know the mockups don't explicitly show what should be done here, but Alex mentioned before when I was working on the account manager bits that the urlbar search throbber could show up when the user types in the location bar. Currently, the throbber lives in the same place as the favicon, so the removal of the favicon happens to remove the urlbar throbber. Not sure if this is the intended end result or if a followup bug should be filed to re-add it.

The patch leaves most of the code backing the throbber alone, so it can be added back in a followup. (I don't know where it would be added, which is why I didn't do it here.)

Dao, are you using Stephen's mockups as an intermediate step towards Alex's? No offense to Stephen, but Alex's look better.

They look the same to me. But what I don't understand is why domain's name is in both identity box and adress bar itself.

(In reply to comment #15) > Dao, are you using Stephen's mockups as an intermediate step towards Alex's? Yes. With our current resources, we estimate that we will have time to implement the portion of Alex's design that is shown in Stephen's mockup for Firefox 4. If you would like to see the entirety of Alex's design in Firefox 4, patches are welcome. :)

Sadly I'm but a mere user with not enough knowledge to be of any assistance. For the time being, I'll just make googly eyes and bug the devs.

>offense to Stephen, but Alex's look better. My earlier mockup was using graphics from Stephen, so really they are all Stephen's mockups :) His most recent one is definitely what we want to go with though, matches the soft feel of all of the other controls.

Most recent one being this? https://bug587901.bugzilla.mozilla.org/attachment.cgi?id=466942

yes

Comment on attachment 468985 [details] [diff] [review] patch A couple questions: 1) This seems to remove usage of the searching_16.png throbber (used when Places is taking its time to show results). What's the plan here? [I see an attribute being set, is this going to be used by some other bug to display it elsewhere?] 2) Setting browser.identity.[ssl_]domain_display to 0 seems quite odd now, because you just get a little square button containing just a dropdown arrow. Did UX consider this case? Maybe it should have the generic favicon (or even the real favicon), for people who want to retain roughly the FF3 style? Maybe -moz-element makes this easyish?

The throbber only appears when the user is editing the field, so I don't see why it would be in conflict with any of the changes (in that state the identity block and URL should not be present) For the normal case we should be showing the domain name in the block, as detailed in Stephen's mockup. Redundancy will be addressed in a different bug.

(In reply to comment #22) > 1) This seems to remove usage of the searching_16.png throbber (used when > Places is taking its time to show results). What's the plan here? [I see an > attribute being set, is this going to be used by some other bug to display it > elsewhere?] Yes, that's my plan. Alex: the throbber replaces the favicon when it shows up. With the favicon being gone, this doesn't work anymore. > 2) Setting browser.identity.[ssl_]domain_display to 0 seems quite odd now, > because you just get a little square button containing just a dropdown arrow. > Did UX consider this case? Maybe it should have the generic favicon (or even > the real favicon), for people who want to retain roughly the FF3 style? Maybe > -moz-element makes this easyish? It actually doesn't look too bad to me, but it's a hidden pref anyway, so I'd rather not care about it right now.

Comment on attachment 468985 [details] [diff] [review] patch What's the bug # for replacing the Places throbber?

This landed as http://hg.mozilla.org/mozilla-central/rev/1633907c75b7 I backed it out because it caused several test failures. http://hg.mozilla.org/mozilla-central/rev/225690b9d9f6 http://hg.mozilla.org/mozilla-central/rev/360f315ba90a

The Win7 mochitest failures happened thanks to DirectWrite (e.g. bug 578620). I don't know what's going on with the orange debug builds (Linux http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1283934773.1283935324.29779.gz - Linux64 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1283934774.1283935426.30306.gz - Win2003 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1283934773.1283946842.809.gz).

this should fix the directwrite issue

with Nightly, Mozilla/5.0 (Windows NT 6.1; rv:2.0b6pre) Gecko/20100908 Firefox/4.0b6pre ID:20100908040849 1pix(?) height difference.

(In reply to comment #30) > Created attachment 473034 [details] > screenshot > > with Nightly, > Mozilla/5.0 (Windows NT 6.1; rv:2.0b6pre) Gecko/20100908 Firefox/4.0b6pre > ID:20100908040849 > > 1pix(?) height difference. That's the DirectWrite issue I was talking about.

(note: although backed out, it did end up being in the nightly) I started a dev-apps-firefox thread which people can use to chart their reactions to this change. I encourage everyone to give it some time; it's a big one, so let yourself take time to get used to it: http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/65860ba35715d2a5#

test and nsSidebar.js fixes relanded: http://hg.mozilla.org/mozilla-central/rev/d843b4e06f1b

I notice the following issue with this new indicator: 1) While viewing this Bugzilla page, go to the location bar and enter any text (e.g., "t"). Now the indicator goes grey, as expected. 2) Press Ctrl+Z (or the equivalent on your OS). Now the indicator remains grey. I think I would expect the indicator to revert to its previous colour after Step 2. Perhaps the colour could revert whenever the URL is correct? (As far as I can tell, the only way of getting the colour back is by clicking the indicator or by refreshing the page.)

(In reply to comment #31) > (In reply to comment #30) > > Created attachment 473034 [details] [details] > > screenshot > > > > with Nightly, > > Mozilla/5.0 (Windows NT 6.1; rv:2.0b6pre) Gecko/20100908 Firefox/4.0b6pre > > ID:20100908040849 > > > > 1pix(?) height difference. > > That's the DirectWrite issue I was talking about. I have D2D/DW/D3D OFF. so seems to be nothing to do with DW ?

(In reply to comment #34) It's not a new issue. The old indicator's favicon behaved exactly this way. Press Esc.

(In reply to comment #35) > I have D2D/DW/D3D OFF. > so seems to be nothing to do with DW ? It could also be your font behaving differently due to your OS locale.

It is, thankfully, still possible to hide the tab bar (with a single tab) and to move the new tab button to the toolbar. Therefore, since this is a perfectly reasonable and supported scenario, there should be an option to keep the favicon in the urlbar.

Where is "indicator for sites without identity information"? The original mockups form Alex showed white identity box for those sites (http), but I don't see it. Plus, and I'm asking again, why is site's domain's name displayed outside identity box?

(In reply to comment #39) > Where is "indicator for sites without identity information"? The original > mockups form Alex showed white identity box for those sites (http), but I don't > see it. My appologize, it was caused by add-on.

The remaining half of this work is tracked in bug 588270. (which wasn't listed as a dependency here, unfortunately)

Should I file a new bug for cosmetic changes or is this still a WIP? The color of the blue and green blocks don't match the mockup. The blue one seems too dull and the green one too bright. The same goes for the text color on the blue and green blocks. Both have dark grey text instead of dark blue and dark green. Also, the border colors are too dark.

I'll comment here since this bug is still open. Opening a new tab results in just a grey drop-down box on the left side of the location bar which looks really weird, outplace, not useful, and in a way redundant. In a way redundant due to the location bar having a drop-down arrow button on the right side of the location bar even though these two have completely different functions.

(In reply to comment #41) > The remaining half of this work is tracked in bug 588270. (which wasn't listed > as a dependency here, unfortunately) That work isn't targeted for Firefox 4; should this half be backed out and retargeted at some future milestone?

More incremental steps: http://hg.mozilla.org/mozilla-central/rev/82ba281b4703 http://hg.mozilla.org/mozilla-central/rev/23e49f8ab15b (In reply to comment #44) > That work isn't targeted for Firefox 4; should this half be backed out It has been backed out yesterday. The bulk of the patch didn't relanded and I'm not going to reland it.

previous patch was incomplete

(In reply to comment #45) > More incremental steps: > http://hg.mozilla.org/mozilla-central/rev/23e49f8ab15b Ooops, the winstripe part would increase the location bar height as long as the favicon is still there. Backed out: http://hg.mozilla.org/mozilla-central/rev/94a0c347256d

A bit in line with what comment #43 described (fixed on Mozilla/5.0 (Windows NT 6.0; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre ID:20100909041137) I ended up here. I believe the indicator shouldn't appear on about:* pages as technically these are not web sites, yet the indicator claims: "This web site does not supply ownership information. Your connection to this web site is not encrypted. <More Information...>" Can this be resolved on this bug or a new one is in order? Thanks and keep up the great work!

(In reply to comment #50) > I believe the indicator shouldn't appear on about:* pages as technically these > are not web sites, yet the indicator claims: > "This web site does not supply ownership information. > Your connection to this web site is not encrypted. <More Information...>" > > Can this be resolved on this bug or a new one is in order? See bug 432809. The about:* pages need special handling. If a separate bug is needed, feel free to expand that one to cover all about:* or make a new one and dupe it forward. Either or.

(In reply to comment #43) > Created attachment 473295 [details] > new tab drop-down arrow > > I'll comment here since this bug is still open. Opening a new tab results in > just a grey drop-down box on the left side of the location bar which looks... Anything change in the recent patches to fix this issue?

(In reply to comment #51) > See bug 432809. The about:* pages need special handling. If a separate bug is > needed, feel free to expand that one to cover all about:* or make a new one and > dupe it forward. Either or. Thanks! That one looks like it. I don't have enough "bugzilla chi" to duplicate and such. Can that one be made a dependency of this one?

(In reply to comment #53) > (In reply to comment #51) > > See bug 432809. The about:* pages need special handling. If a separate bug is > > needed, feel free to expand that one to cover all about:* or make a new one and > > dupe it forward. Either or. > > Thanks! That one looks like it. > I don't have enough "bugzilla chi" to duplicate and such. > Can that one be made a dependency of this one? Sure. Done. My "Bugzilla chi" is a couple levels above you. :p I've added bug 432809 as a dependent here and we'll just expand its scope to cover all about:*. Needs to be dealt with one way or another as the "identity information" for these pages isn't really helpful as-is.

>> That work isn't targeted for Firefox 4; should this half be backed out > >It has been backed out yesterday. The bulk of the patch didn't relanded and I'm >not going to reland it. What's the current status here? Did we back the change out because the patch wasn't complete (but we were ok with the general idea) or because we want to land this simultaneously with bug 588270?

The patch was complete as far as this bug is concerned. As a result of the discussion in mozilla.dev.apps.firefox, bug 588270 has been added as a new dependency.

(In reply to comment #36) > (In reply to comment #34) > > It's not a new issue. The old indicator's favicon behaved exactly this way. > > Press Esc. Isn't it related to bug 420218 ? (it's still present on Fx 3.6 ; On my Power Book today, so I don't know about it in nightly)

I was thinking some food for thought, this might also be a good place to move the security lock out of the status bar and into this box here like Chrome, even if its in the identity popup, its still a nice piece of visual without having to click, as I don't think most users know the meaning of the color coded identities yet, but are habitually used to seeing the lock icon.

(In reply to comment #58) I thought we had all agreed the lock was slated for death in the top-level GUI? Too many people think lock==safe, which isn't true. You can encrypt a connection to the scammers secured server. Thus, the crusade to kill the bad indicators.

(In reply to comment #59) > (In reply to comment #58) > I thought we had all agreed the lock was slated for death in the top-level GUI? > Too many people think lock==safe, which isn't true. You can encrypt a > connection to the scammers secured server. Thus, the crusade to kill the bad > indicators. IIRC, the UX team had advocated for the removal of the lock icon. It can also be phished with favicons. This is mitigated by the removal of the favicon from the location bar, but favicons will still show up on tabs, of course, so we don't want users to think that a lock means secure, when we have better indicators (EV, etc.).

>I thought we had all agreed the lock was slated for death in the top-level GUI? >Too many people think lock==safe, which isn't true. Yes, our strategy is about identity, not security. The existence of the lock icon in the status bar in Firefox 3 was an odd UI compromise to satisfy limited dissent.

I'm setting this particular bug to wontfix, and filing a series of follow up bugs. Short term changes for Firefox 4: Bug 610048 - Move the site favicon outside of the site identity block Bug 610053 - Land the new site identity block graphics Long term plan after Firefox 4: bug 588270 - Reduce redundancy with the site identity block + URL