Alice0775 White Reporter
	Description • 14 years ago

      No description provided.

	Alice0775 White Reporter
	Comment 1 • 14 years ago

Because the screen position of the hyperlink address in Location Bar are different by length of the URL, It is hard to judge url instantly.

	Alice0775 White Reporter
	Comment 2 • 14 years ago

I have trouble to look for the indication point of the domain of the hyperlink URL.
Eyes are at a loss in right and left.

	Csaba Kozák [:WonderCsabo]
	Comment 3 • 14 years ago

Actually, the target link should replace the whole current link, i think.

	Alice0775 White Reporter
	Comment 4 • 14 years ago

Yes, The start position should be always same.

	Frank Yan (:fryn)
	Comment 5 • 14 years ago

I recommended this in the main bug.

Two compelling advantages of having the url left-aligned:

1. We almost always begin reading the url from left-to-right, so we should maintain the same starting location (as Alice stated in comment 4).

2. If the urls of two adjacent links happen to have the same prefix, then we will only notice the change in the suffix, since the rest does not move, so it will conveniently draw our attention to the difference.

	Drew Willcoxon :adw
	Comment 6 • 14 years ago

Yes, we are planning to do this for Firefox 4 final.  See Limi's bug 587908 comment 95.  Excerpt:

* We should aim to start the hovered domain display at the same offset every
time — 50% seems like it's the most balanced, but open to other suggestions.

	Ed Lee :Mardak
	Comment 7 • 14 years ago

One potential caveat when implementing this is that the identity box area changes size based on the text shown (domain or EV) and notificatino icons, so calculating the halfway point might get tricky.

	Sean Smith
	Comment 8 • 14 years ago

Regarding comment 7, you'd only need to determine the width of:
.autocomplete-textbox-container.urlbar-textbox-container

domI tells me the width of that element, and it changes based on http sites or https sites.

	Matthew Turnbull [Bluefang]
	Comment 9 • 14 years ago

I don't think the offset should be 'hard coded' at a particular position. As long as the start point is consistent on a per-page basis, I think it willl be ok.

So, in that regard, I think the target URL should be left-aligned to the current URL (with some left-padding). If the current URL is longer than ~50% of the URL bar, truncate it and left-align the target URL to ~50%.

This way:
* We show as much of both URLs as possible, without giving unfair weight to the current URL. 
* The starting position of the target URL is consistent when mousing over a page, improving readability.
* We avoid having large, blank gaps when the URL bar is very wide.

	Ilhan Yumer
	Comment 10 • 14 years ago

Eyes are at a loss in right and left and somewere between. It is really annoying.

Which place is easy to find? The middle of the location bar or the left bottom of the window?

If you set it to the middle then we will not be able to see the end parts of the current url.

The best thing to do is to set the status bar as default and show the target url in the status bar.

	Lawrence Newton
	Comment 11 • 14 years ago

(In reply to comment #10)
Or remove the status bar and show target URL in lower left window corner as tooltip in parity to IE9 and Chrome.
Try (Link Target Display) https://addons.mozilla.org/en-US/firefox/addon/55724/ from Dao Gottwald.

	Paul [pwd]
	Comment 12 • 14 years ago

Said this in the initial bug:
surely right aligned is easier. I remember seeing something about clicks
bouncing off of corners, surely the goes for looking at things. if the size of
the window changes, you're looking somewhere different to where you would if
the window was maximised. Right aligned is always top right of the browser
(minus however many pixels for buttons and/or search box).

	Alex Limi (:limi) — Firefox UX Team
	Comment 13 • 14 years ago

(In reply to comment #12)
> surely right aligned is easier. I remember seeing something about clicks
> bouncing off of corners, surely the goes for looking at things. if the size of
> the window changes, you're looking somewhere different to where you would if
> the window was maximised. Right aligned is always top right of the browser
> (minus however many pixels for buttons and/or search box).

That's not the point, though. Most of the time, you're looking for which domain it points to, and having that part of the string always start in the same location makes it easier to scan for.

The other compelling reason is that the jumping around of the separator is a lot more distracting than having the separator show up in the same spot every time (habituation).

	Ilhan Yumer
	Comment 14 • 14 years ago

(In reply to comment #11)
> (In reply to comment #10)
> Or remove the status bar and show target URL in lower left window corner as
> tooltip in parity to IE9 and Chrome.
> Try (Link Target Display) https://addons.mozilla.org/en-US/firefox/addon/55724/
> from Dao Gottwald.

Agree,
and; show the url without any visual effect (such as delay).

	Mitchell Field [:Mitch]
	Comment 15 • 14 years ago

Left-aligning the target location on hover would also help alleviate (but not prevent for longer URLs) the obscuring when an item on the tabs list is hovered over.

	Paul [pwd]
	Comment 16 • 14 years ago

(In reply to comment #15)
> Created attachment 476198 [details]
> Screenshot of "list all tabs" obscuring location
> 
> Left-aligning the target location on hover would also help alleviate (but not
> prevent for longer URLs) the obscuring when an item on the tabs list is hovered
> over.

not sure how. once the css bugs have been fixed the flicker will be gone. On the other hand right aligning allows for the full url to be seen at all time, whether long or short, left aligned means that it will have to be truncated if over a certain length.

	Mitchell Field [:Mitch]
	Comment 17 • 14 years ago

I don't know what flickering has to do with my screenshot. It is obvious from said screenshot that the URL is cut off as-is.

	Emanuel Hoogeveen [:ehoogeveen]
	Comment 18 • 14 years ago

Why not replace the URL in the location bar on mouse-over of a link, but make the text blue or something to indicate it's not the current address?

	Andrea
	Comment 19 • 14 years ago

(In reply to comment #18)
> Why not replace the URL in the location bar on mouse-over of a link, but make
> the text blue or something to indicate it's not the current address?

I agree.
Additionally, this way the user can also edit rapidly a link URL (for example, if he wants to visit a slightly different URL he knows the existence of).
I don't think it's necessary to show both the current and the link URL at the same time.

	Jaquez
	Comment 20 • 14 years ago

(In reply to comment #19)
> (In reply to comment #18)
> > Why not replace the URL in the location bar on mouse-over of a link, but make
> > the text blue or something to indicate it's not the current address?
> 
> I agree.
> Additionally, this way the user can also edit rapidly a link URL (for example,
> if he wants to visit a slightly different URL he knows the existence of).
> I don't think it's necessary to show both the current and the link URL at the
> same time.

While I don't LOVE the idea of splitting the location bar either, I don't think it's a good idea to simply replace the text in-place for security reasons.  Changing the color MIGHT alleviate the problem somewhat, but it's too easy to confuse the user into thinking the target location is the current location that way.

I use the Locationbar^2 add-on which provides this exact behavior.  When I am hovering over a link, I am certainly well aware of what it indicates, but occasionally, I will click on a link, visit the target, and then come back to the original page.  When this happens, the visited link still has focus and so it's target is shown in the location bar.  I'm a knowledgeable, advanced user, and this still trips me up sometimes.

Given the ability to focus a link on page load through javascript, this could make for a REALLY convincing phishing attack: The page looks right, the url in the location bar is right, I must be at my bank; I'll log in.

Remember, it's too easy to not understand the meaning of (or simply not notice) different color of the text and so misunderstand what page you're on.

Unfortunately, I don't know what the ideal solution to this problem is but I think that the above provides compelling reasons not to go that route.

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 21 • 14 years ago

Limi: are we sure we want to do that? Is the rationale muscle memory or something (eye muscle?) Not sure that the solution is ideal, as it means cutting off part of URLs all the time instead of optimizing depending on length.

Not blocking, but feel free to renominate in case I've missed something.

	Alex Limi (:limi) — Firefox UX Team
	Comment 22 • 14 years ago

(In reply to comment #21)
> Limi: are we sure we want to do that? Is the rationale muscle memory or
> something (eye muscle?) Not sure that the solution is ideal, as it means
> cutting off part of URLs all the time instead of optimizing depending on
> length.

Yes, it moves elements around, and makes it hard to scan for the start of the URL when it moves around.

However, we do need to have some logic that crops it the right way if you do pathologically long subdomains, but that is something we need to do no matter how we align this one.

> Not blocking, but feel free to renominate in case I've missed something.

I agree that the currently shipping code is good enough for beta7, the rest I'd consider as polish. This isn't blocking anymore, since it's actually in the product now. :)

	Paul [pwd]
	Comment 23 • 14 years ago

As a user, I just can't subscribe to the idea that having truncated target URLs is superior to having them move around in order to disclose the full target URL. The idea that having a moving starting point for target URLs are distracting is one that doesn't even make sense. When a user browses, their eyes are fixed on the viewpoint until such a point the user averts them, thus users seldom see 'flickering'. The ideology of this bug seems to be about fixing a problem that just doesn't exist. If a user hovers over a URL long enough to look up and check where it's leading them, it's because they want to know where it's going, not because they want a vague idea of where it's going. The gains of the left aligned target URL are based on visual consistency and that's just not enough. Users will learn to read URLs just fine with the moving starting point as soon as they get over the initial shock of the change.

	Dan Dascalescu
	Comment 24 • 14 years ago

As soon as I migrated to 4.0b7, I noticed that I could no longer see the target URL in the status bar on hover. The location bar is too short for it, and the right alignment was annoying, because I had to shift focus constantly to locate the start of the URL.

IMO, the URL should be displayed in the status bar, but there are so many bugs for that, that I couldn't figure out in a reasonable length of time where to vote for bringing it back, save for http://firefox.uservoice.com/forums/57440-firefox-4-beta/suggestions/1217833-bring-back-the-status-bar

Personally, I installed Status-4-Evar, but I also agree that wherever the target URL is displayed, it should be aligned to where text starts in the user's locale (left, for most of the world).

	[not reading bugmail]
	Comment 25 • 14 years ago

(In reply to comment #24)
> IMO, the URL should be displayed in the status bar, but there are so many bugs
> for that, that I couldn't figure out in a reasonable length of time where to
> vote for bringing it back, save for
> http://firefox.uservoice.com/forums/57440-firefox-4-beta/suggestions/1217833-bring-back-the-status-bar

That is why I opened bug 599212 as an alternative.

	Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
	Comment 26 • 14 years ago

Any chances to get this fixed in Firefox4 ?

	Alex Limi (:limi) — Firefox UX Team
	Comment 27 • 14 years ago

I think that the improvements in bug 625945, bug 625952 and bug 625956, URLs would get much more space and be a lot easier to scan/parse, visually.

Middle-aligning it has some obvious downsides (obscuring the current URL more often than necessary) and some upsides (consistent starting point for the eye), so I'd like to see us land those first, then see if this is still needed.

	Philipp von Weitershausen [:philikon]
	Comment 28 • 14 years ago

(In reply to comment #27)
> Middle-aligning it has some obvious downsides (obscuring the current URL more
> often than necessary)

What's so bad about obscuring the current URL? Also, I think the suggestion was to left-align.

> and some upsides (consistent starting point for the eye),

I think that's a pretty big upside. I wonder if bug 625945, bug 625952 and bug 625956 could be made to tie into this bug. Let's say you're at http://example.com and you hover over a link to http://example.com/foo/bar. We could keep showing the http://example.com portion in black and append the new path in grey, suggesting that that's the new link we're going to.

	Alex Limi (:limi) — Firefox UX Team
	Comment 29 • 14 years ago

(In reply to comment #28)
> I think that's a pretty big upside. I wonder if bug 625945, bug 625952 and bug
> 625956 could be made to tie into this bug. Let's say you're at
> http://example.com and you hover over a link to http://example.com/foo/bar. We
> could keep showing the http://example.com portion in black and append the new
> path in grey, suggesting that that's the new link we're going to.

Agreed, and we had that in the initial proposal. We will probably do this, but not sure it's wise to attempt so close to the FF4 release, as it's a different type of approach for a particular class of links.

If it's a trivial patch, I'd love to see how it looks and works.

	Dan Dascalescu
	Comment 30 • 14 years ago

> Let's say you're at
> http://example.com and you hover over a link to http://example.com/foo/bar. We
> could keep showing the http://example.com portion in black and append the new
> path in grey, suggesting that that's the new link we're going to.

What if the new link is a totally different site from example.com?

The current address and the target address are conceptually different items, and they need to be displayed in a visually different manner. This gives us two choices: display them in relatively the same space, or separately.

Displaying them in the same space has been discussed enough to show its disadvantages. Displaying the target anchor in a separate location (the status bar) had never controversial, except for one thing: vertical space used by the status bar. Since the addon bar uses the same vertical space, this point is moot.

We can therefore use the solution that has been working for a long time: display the target anchor in a bar at the bottom of the browser window.

	jag (Peter Annema)
	Comment 32 • 14 years ago

I would say 33% is better than 50%, though the white space (literally) after short preview URLs looks a bit odd. I think we need some kind of visual full stop there.

	Siddhartha Dugar [:sdrocking]
	Comment 33 • 14 years ago

Why is this being done if Bug 541656 will be resolved?

	jag (Peter Annema)
	Comment 34 • 14 years ago

Have we definitively decided to show preview URLs in the floating status panel, and abandoned any future attempts at displaying them in the location area?

	Siddhartha Dugar [:sdrocking]
	Comment 35 • 14 years ago

Fixed with Bug 541656

	jag (Peter Annema)
	Comment 36 • 14 years ago

I wouldn't say "fixed" so much as "mooted", at least for the 4.0 release.