The "hovered link" indicator in the URL bar + the state indicator changes landed for beta 7, but in a halfway done state. Here's what remains: * Right-aligned URL is hard to scan and causes a lot of jumping around, instead anchor location in the middle at consistent starting point for more efficient visual parsing. * Show “Connecting to example.com…” (or whatever the current string is) *only* for pathological cases, e.g. when we have been waiting for a server more than 3-5 seconds for a server to reply — you generally only need it when you are wondering why stuff is taking so long, * Drop http:// from the preview, and drop hostname if it’s on the same domain, * Both the bookmark star and the pulldown indicator disappear when you hover, contributing to the visual noise of hovering (by flickering in and out), I suggest that we keep these in the display even on hover to minimize noise. This will be reduced by the new bookmark star graphics, though — so prioritize the other items first. :)

(In reply to comment #0) > * Show “Connecting to example.com…” …in the right-hand side of the URL bar, that is.

Adding some thoughts from Kevin Fox, we actually had this in the initial mock-ups too: > I'm not sure if this would be a step in the right direction or away from it, but have you guys played with sliding the new URL to the left on click, cementing the behavior of moving the url from a preview to the actual location? > Extending the metaphor beyond what is wise, what if the back and forward buttons leveraged the same metaphor, where hitting back would slide the 'current' url to the right, replaced by the historic url? In fact, if you're in your own history, the url preview could be persistent and show the next url in the 'forward' queue. > Again, I'm not saying this is a *good* idea, but trying to figure out how to augment and extend the current navigational metaphors might have merit. …just so we have them noted. The initial list of fixes have priority, but this might be an interesting experiment to do if it isn't too hard to test.

>* Both the bookmark star and the pulldown indicator disappear when you hover, >contributing to the visual noise of hovering (by flickering in and out) the deactivated star on windows is pretty light and doesn't seem to be a problem in terms of visual noise. If we keep the star we lose some more room, and it kind of looks like you have bookmarked the link you are about to travel to (we to some extent use bookmarks as a form of security indicator, for instance, "this isn't my bank, it isn't bookmarked").

(In reply to comment #0) > * Right-aligned URL is hard to scan and causes a lot of jumping around, instead > anchor location in the middle at consistent starting point for more efficient > visual parsing. I don't see how you do this without 1) sometimes unnecessarily covering up the end of the current URL with the link target, 2) sometimes creating an unpleasing gap between the current URL and the link target, 3) sometimes creating unpleasing gaps both between the current URL and link target and between the link target and the end of the location bar, and 4) reducing the amount of space available to the link target. Anyway, I've asked for a design doc for this before. It should detail exact offsets and widths and other junk I can't think of because I'm not a designer. Could you make one please? > * Both the bookmark star and the pulldown indicator disappear when you hover, The pulldown indicator doesn't disappear... (In reply to comment #3) > the deactivated star on windows is pretty light and doesn't seem to be a > problem in terms of visual noise. If we keep the star we lose some more room, > and it kind of looks like you have bookmarked the link you are about to travel > to (we to some extent use bookmarks as a form of security indicator, for > instance, "this isn't my bank, it isn't bookmarked"). You guys don't even agree. You didn't agree on right-aligned vs. left aligned either. What's the person implementing this supposed to do?

>You guys don't even agree. You didn't agree on right-aligned vs. left aligned >either. What's the person implementing this supposed to do? yeah, sorry about that. We can usually reach agreement quickly, and normally we try to get stuff lined up prior to starting too much of the implementation work.

(In reply to comment #4) > I don't see how you do this without 1) sometimes unnecessarily covering up the > end of the current URL with the link target, 2) sometimes creating an > unpleasing gap between the current URL and the link target, 3) sometimes > creating unpleasing gaps both between the current URL and link target and > between the link target and the end of the location bar, and 4) reducing the > amount of space available to the link target. I don't think those are major issues, but I'm willing to be proven wrong. :) > Anyway, I've asked for a design doc for this before. It should detail exact > offsets and widths and other junk I can't think of because I'm not a designer. > Could you make one please? I believe just doing it at 50% offset should work, i.e. anchored to the middle. All the other code already does the right thing (ellipses, shadows, etc), so I don't think the change needs to be more complex than that. > > * Both the bookmark star and the pulldown indicator disappear when you hover, > > The pulldown indicator doesn't disappear... My fault, you're right. That part is OK, then. > (In reply to comment #3) > You guys don't even agree. You didn't agree on right-aligned vs. left aligned > either. What's the person implementing this supposed to do? That last one was more of a comment (hence why I said to postpone working on it), and I think we're OK with keeping it once the new bookmark star lands. Ignore that part. :) (Sometimes we think out loud in bugs, I apologize for not making that clearer)

> 1) sometimes unnecessarily covering up the > end of the current URL with the link target, 2) sometimes creating an > unpleasing gap between the current URL and the link target, 3) sometimes > creating unpleasing gaps both between the current URL and link target and > between the link target and the end of the location bar, and 4) reducing the > amount of space available to the link target. yeah, all 4 of those will now be true (at varying times), but we do pick up a consistent start place when scanning more than one URL. I'm mostly indifferent on this change. I'll go away now :)

Aside from the deficiencies of the status-in-the-address-url, I think the status should also be visible as an item in the add-ons toolbar by default and be removable via "Customize Toolbar.." if people don't want it or want it somewhere else.

This a mockup a user send us at our forums (sorry the mockup is in Spanish) Original post: http://www.mozilla-hispano.org/foro/viewtopic.php?p=38803#p38803 (es)

This a mockup a user send us at our forums. Reload button and http are not present to give more space to the preview. Original post: http://www.mozilla-hispano.org/foro/viewtopic.php?p=38803#p38803 (es)

(In reply to comment #9) > Created attachment 493531 [details] > Mockup for loading, waiting, reolving states at urlbar > > This a mockup a user send us at our forums (sorry the mockup is in Spanish) > > Original post: http://www.mozilla-hispano.org/foro/viewtopic.php?p=38803#p38803 > (es) I'm working on implementing this in bug 603777, if you're interested in following along.

This is a meta bug, didn't mark it as such earlier. Adding the missing indiviual bugs shortly.

Fixed with Bug 541656