User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101 Firefox/5.0 Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101 Firefox/5.0 This is a request to get a feature akin bug 587908 right. == Explanation: Above mentioned bug was about levering the location bar by moving the information about the targets of hovered links from the (then) to-be-removed status bar to it. As far as I understand, bug 541656 was instead implemented in the final Firefox 4, because some critical features weren’t implemented into the link target display in the location bar in time. I know of no other shortcomings that the chrome-like pop-up doesn’t share (e.g. that both can display a shorter part of a long URL than the status bar could) Please elaborate further problems that have to be addressed before reintroducing the link target display in the location bar. == Implementation The implementation was removed from (I think) Firefox 4 Beta 12, and externalized into the add-on https://addons.mozilla.org/de/firefox/addon/link-location-bar/ Up next, my ideas on a possible implementation: 1. The truncating/shortness of the URL: This is a hard one, since the user has to see part of the current URL to understand that the arrow means “if you click, this URL changes to that URL” Maybe we can start with the right half, and then slowly and unobtrusively extend the width of the link target, until it covers the full location bar. we should also make URL and link location visually different (e.g. lighter colour to indicate that it isn’t the current status) 2. No location bar in full-screen mode: This is easier, and I can think of multiple solutions: • Show the navigation toolbar I don’t really like this one. The navigation toolbar is a clunky piece and contains many buttons, bells and whistles that can’t be clicked when the toolbar is shown on link hover. • Show the location bar alone, at the very top of the screen …or a bar that looks like it. This would be the same as the current implementation, but looking like the location bar, and only present in fullscreen mode. The shortness-problem can be avoided by making it full-width unless the mouse cursor would be in the area it covers, in which case it would span the half of the screen on which the cursor isn’t (see attachment) == Note As Dave Garrett pointed out in bug 541656, comment 113, I should file a new bug, since bug 587908 was invalidated by bug 541656, and these closed bugs are no place to discuss a new/extended reintroduction of a scrapped feature. Reproducible: Always

btw, css-transitions may be used here to make the smooth animation of hovered link if it is hovered for long. That would look nice.

For reference, this long discussion explains the original rationale for moving link targets to the location bar, and the rationale for removing that feature in Firefox 4: https://groups.google.com/d/topic/mozilla.dev.apps.firefox/1Rz8LO3qmpA/discussion

(In reply to comment #3) > For reference, this long discussion explains the original rationale for > moving link targets to the location bar, and the rationale for removing that > feature in Firefox 4: > https://groups.google.com/d/topic/mozilla.dev.apps.firefox/1Rz8LO3qmpA/discussion Do you mind giving a summary of this large discussion (or asking someone who wants to do it)? I was subscribed to bug 587908, but still I see this discussion for the first time. Thus I think that it would be fair to give me (and everyone else who missed the discussion) a summary. I’d have been glad to partake, but since I wasn’t given the chance to do so, I don’t want to be forced to read it afterwards. I’d just feel pranked ;)

I won't attempt to summarize the entire thread (81 messages, many of which go into great depth) in a Bugzilla comment. But here's *my* view of the key points from that discussion: Some reasons the link target was moved to location bar in Fx4 beta: * Makes the UI more self-describing, and helps new users understand URLs and the address bar. * Uses less screen space. Some of the problems with the change as implemented: * It is disruptive to users who are used to previous versions, or who switch between browsers. * It hid information about loading status. * The target in the location bar is right-aligned, making it harder to quickly glance at (since the start of the text is not in a predictable place). The overall conclusion after much discussion was that the problems outweighed the benefits, and the current Chrome-like UI was chosen as the best compromise option that could be implemented and shipped in time for Firefox 4. Some proposals were brought up to mitigate some of these issues; some of the proposals were originally targeted for Firefox 4 but were not ready in time. If you don't read the whole thread, at least check out these two posts which provide detailed explanations of most of the above points: https://groups.google.com/d/msg/mozilla.dev.apps.firefox/1Rz8LO3qmpA/kwx29DwKB3AJ https://groups.google.com/d/msg/mozilla.dev.apps.firefox/1Rz8LO3qmpA/9r-hMs-lLfUJ

ok, i guess that i will read it now -.- according to Dave Garrett, there is the aspiration to develop a better way, so i think this bug should be marked as confirmed. in a follow-up post, i’ll write more about possible solutions to the problems you mentioned.

let’s go: == break from custom == i don’t really get in which places this is a concern and in which it isn’t, nor where it is acceptable to implement options, nor where these options are only on about:config (as opposed to being in the settings dialogue) what we do in such cases is afaik one of these: • we changed it, so it’s sink or swim, guys • you have a checkbox in the settings window for that • go to about:config, find a (hopefully not too) cryptic key for the setting, edit it • ok, we don’t change it (well, we did already, so that’s not an option here) == loading progress information we could possibly do this automatically; when loading from a 3rd-party server takes too long, e.g. an arrow panel could pop up and tell the user how to view the loading information/log. this piece should be • unobtrusive or hidden when not needed • visible when needed this can possibly be achieved in multiple ways: • hidden per default, provide a way to show it temporarily • show permanently (somewhere) • replace with a log hidden solution: the loading indicator on tabs is a passible place for it. a possible other place for the button is the reload button. on click, an arrow panel can then do the job of showing the progress. permanent solution: for this, we should at least replace the textual indication (waiting for, transferring data from) with the new spinning load indicators for consistency. also, we should find a better place for it. log solution: the web console (ctrl+shift+k) provides this functionality, the user justs needs to be informed of that. == alignment to the right the only solution to that one is making it left-aligned. what i can think of is the following: 1. hover above a link: after a slight pause (the user could just move the cursor), the arrow appears to the right, and rapidly moves to the left, until it hits the left side of the location bar (the link location moves in with the arrow) 2. move the cursor to another link: the old link location fades to white, then the new one fades in 3. move the cursor away from a link or click on it: the arrow moves rapidly to the right, “erasing” the link location and revealing the current url

Reporter, do you have anything new about this issue?

unfortunately not. do you have any resources to link to/from?

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.