Steps to Reproduce --------------------------------------- 1. Click into the urlbar. 2. Hover a link on the current web page. 3. The hover target wont be displayed in the urlbar. What should have happened: --------------------------------------- The target URL should be displayed. What actually happened: ---------------------------------------- The current URL stayed, the hover target didnt show up in urlbar.

The same Problem arises when you get the Awesomebar Result Popup. Technically not a Regression, but UX/User-wise.

I can confirm on Win7 using an add-on free profile, though I am not certain it is a bug per se. The focus of the browser is in the location bar and not on the page content. In other words, the browser does not (and cannot) know it is hovering over link in the page because it is on the location bar. But, that is just my opinion.

Drew, is this a bug or a feature?

Looking at the code it is meant to be this way which sucks. Users having to click the page or press escape to unfocus the location bar.

Yeah, this is the intended design, although if it turns out not to be the right UX, we should change it. The idea is that if the location bar is focused, naturally the user is focused on it -- typing into it or something -- and therefore a hover link would get in the way. Of course sometimes it's focused when you're not actually focused on it, but there's no way for Firefox to know that. CC'ing Alex for his thoughts, since he's the one who designed this part.

I think it's unnecessary to not to show the hover target when the urlbar is focused. Why? If it is focused, the users are typing, and select a page from the drop-down or simply hit the enter or go button. When working in urlbar, they never move their cursor to a link, only when they actually want to click on that link. Thank for the answer, i'm very interested in Alex's thoughts about this.

(In reply to comment #6) > When working in urlbar, they never move their cursor to a link, only when they > actually want to click on that link. This is the problem: sometimes your cursor is over a link by accident. If you focus the location bar to type, but your cursor is over a link by accident, now you have to move your cursor to get rid of the hover link. So sometimes your location bar is focused by accident -- so you have to unfocus it to see hover links -- and sometimes your cursor is over a link by accident -- so you have to move your cursor to use the location bar.

Maybe a test pilot study tell us wich one is more frequent. Or Alxy already looked on one and made a decision. :) Anyway, for me, the first one is more frequent but i'm not all of the Fx users.

Another reason why having the target link show in location bar is a bad idea. I have yet to see a single reason for why it was considered a good idea in the first place.

>uiwanted In general I think the current behavior is fine. However, if we wanted to get more advanced, we could show a hovered hyperlink even if the location bar is focused, but then clear it on the first keypress. So for instance, if you started typing, you could then hover a link to see it's target, and then keep typing (at which point the hovered link would disappear). That however is an unusual use case. In general, we want the use to focus on what they are typing when they have the location bar focused, and the assumption is that their attention has shifted from the position of the mouse (which may or may not be over a hovered hyperlink) to the location bar where they are entering text.

Thanks for commenting, Alex. I was wondering about what to do with this, and something similar occured to me.

Doesn't block; not going to be a very common use case, I don't think. Kind of sucks, I agree, but I'd want to understand a clean interaction here. Unfocusing the URL bar doesn't seem right, f.e. :)

Mike: So should it be fixed same way (f.e. what Alex described) or not at all?

Yup, as usual, Alex is rightthinking here.

A more common case is when you click on the down arrow in the url bar and then click on the page to close it. The url bar retains focus and hovered urls don't show up. If the list is open due to typing in the bar and you click on the page to close it, focus is returned to the page as expected. Maybe this should be a separate bug.

Yeah, to deal with that case we should just clear any hovered URLs on keypress in the location bar.

(In reply to comment #10) > In general I think the current behavior is fine. However, if we wanted to get > more advanced, we could show a hovered hyperlink even if the location bar is > focused, but then clear it on the first keypress. So for instance, if you > started typing, you could then hover a link to see it's target, and then keep > typing (at which point the hovered link would disappear). That however is an > unusual use case. +1 Might be unusual but I just stumbled into the use case today, while typing away on the location bar I wanted to see what lurked underneath that shiny link but couldn't =( If the hovered link could appear even if there's a text selection on the location bar it would be ideal.

About that +1 to that behavior. I moused over a link which had a long id in it. I wanted to add that ID into my current url so I wanted to hover over it and type what was seen there. So i think you should allow keypressing in the minimized area of the urlbar, because people may need to copy something from a hovered link location. The other way which should not be forced is: copy link location, find somewhere to paste it. Copy the section you need. Go back to urlbar and paste it. This is very tedious

Fixed with Bug 541656