We need an alternative way to display URLs in order to make browsing without a status bar feasible. We could display them in the location bar (the Fission extension does this), but I found that slightly strange, and it's not an option for full-screen mode. A tooltip near the mouse (like Opera does it, I think) seems too distracting, as you don't want to look at the URL in all cases. So I propose we follow Chrome. Try server build: https://build.mozilla.org/tryserver-builds/dgottwald@mozilla.com-try-69b4af1af901/

Comment on attachment 423136 [details] [diff] [review] patch I'm in favor of trying to leverage the location bar for this information. It seems to be a more natural mapping for the information, and we are interested in removing all Firefox specific UI from the status bar so that we can free the space to be entirely used by extensions. (perhaps even to go as far as to rename it the extension bar).

(In reply to comment #1) > (From update of attachment 423136 [details] [diff] [review]) > I'm in favor of trying to leverage the location bar for this information. It > seems to be a more natural mapping for the information, So have you tried the extension that I mentioned? What about full-screen mode? > and we are interested > in removing all Firefox specific UI from the status bar How is that an argument against the proposed popup?

The location bar also doesn't work at all for URLs from the history or bookmarks menu...

(In reply to comment #3) > The location bar also doesn't work at all for URLs from the history or > bookmarks menu... While i second your thought, i also want to underline that actually we should have tooltips on most bookmarks/history entries in the UI thanks to latest patches from Gabriele Best. Even if that does not replace the status bar functionality, it is an alternative way to check their addresses without having to open them.

True, but tooltips are a bit slower and aren't an option for keyboard users. It's good to have duplication there.

>True, but tooltips are a bit slower and aren't an option for keyboard users. >It's good to have duplication there. yeah, I agree >> and we are interested >> in removing all Firefox specific UI from the status bar > >How is that an argument against the proposed popup? not specifically an argument against, just our most recent thoughts. We could allow extensions to control the entire surface area of the status bar, and then use this type of approach with pup-ups slightly higher, so the ideas don't really collide. >What about full-screen mode? maybe just tool tips? I'm not really sure, but it seems like if the user went into full screen mode they are interested in not running into our UI as often, although it could be different if they are always running Firefox in full screen mode on a netbook, in which case they might actually like the feedback. >So have you tried the extension that I mentioned? Yeah I've been using Fission for awhile. (I personally don't like the very visually noisy progress bar filling the entire location bar, but wanted to try that for awhile as well). I wonder if we couldn't encourage people to look at the location bar more, and really reinforce that it is the definitive place for location information if we give it an extra use case. I feel like I glance at the location bar a lot more when running Fission with the pref set to show the hyperlink URLs, but that could also be because a few weeks isn't long enough for the novelty to wear off.

(In reply to comment #6) > >> and we are interested > >> in removing all Firefox specific UI from the status bar > > > >How is that an argument against the proposed popup? > > not specifically an argument against, just our most recent thoughts. We could > allow extensions to control the entire surface area of the status bar, and then > use this type of approach with pup-ups slightly higher, so the ideas don't > really collide. The popup wouldn't even have to be higher, it could just overlay the bar and fade away when you actually want to use the bar. But: I wouldn't want to encourage extensions to use this bar more extensively as their primary UI hook. If the end result was that 30% of our users (those with extensions) would still see the bar, that would be pretty bad. So my thinking is we should keep the status bar as it is, but hidden by default, and show it if an extension uses it, and also display link targets there in that case. But anyway, again, that's not directly relevant for this bug... > >What about full-screen mode? > > maybe just tool tips? I'm not really sure, but it seems like if the user went > into full screen mode they are interested in not running into our UI as often, > although it could be different if they are always running Firefox in full > screen mode on a netbook, in which case they might actually like the feedback. Tooltips have two downsides. First, they appear near the mouse, distracting you when you're not really interested in the URL. I won't read any of the link URLs on this page, for instance, when I know that they'll point to bugzilla.mozilla.org anyway. Second, when you do want to see the URL, tooltips aren't as responsive as I think we want them to be. I published what I'm proposing in this bug as an extension, and people were especially interested in improving the responsiveness (e.g. <http://design-noir.de/log/2009/12/firefox-ie-chrome-screen-real-estate/#comment-15090>). I think all this is important for full-screen mode, too, as this would help making it more useful not only for temporary use. In fact, I think the status bar is the only thing I'm missing there right now -- interaction with tabs and the location bar is pretty good. > >So have you tried the extension that I mentioned? > > Yeah I've been using Fission for awhile. (I personally don't like the very > visually noisy progress bar filling the entire location bar, but wanted to try > that for awhile as well). > > I wonder if we couldn't encourage people to look at the location bar more, and > really reinforce that it is the definitive place for location information if we > give it an extra use case. I feel like I glance at the location bar a lot more > when running Fission with the pref set to show the hyperlink URLs, but that > could also be because a few weeks isn't long enough for the novelty to wear > off. I'm not sure whether you mention this as a positive or a negative point. It makes me slightly nervous and seems to confirm my feeling that it draws attention to this feature too strongly. I really want the display to not distract me when I'm not interested in reading out the URL. We need to provide users with the tools to surf the web with confidence, but forcing them upon users so that they get distracted even when there's no real benefit security wise or in any other way would be overdoing it. This could actually work against your whole idea and train users to eventually ignore the location bar more than they do already. Another problem with replacing the location with link targets is that sites could spoof the location by making the whole page a link while overriding the link cursor with CSS and preventing the link from being executed with JS.

Fission's solution can be confusing for users that have the link focused due to tabbing or clicking on it previously. Steps to reproduce (Example 1 of many possible): 1. Press tab until a link is focused. 2. Scroll the document until the link is no longer visible. 3. The link's url is still displayed in the location bar, even though it is mostly likely no longer relevant to the user. Steps to reproduce (Example 2 of many possible): 1. Click on a link in tab 1 that opens in a new tab 2. The newly created tab 2 is now focused, and its url is displayed in the location bar. 2. Switch back to tab 1, and observe that the link's url (most likely the same as tab 2's unless there was a redirect) is still visible in the location bar, because the link is still focused from the previous click. (In reply to comment #1) > ... we are interested > in removing all Firefox specific UI from the status bar so that we can free the > space to be entirely used by extensions. (perhaps even to go as far as to > rename it the extension bar). Is there a reason that we are going with an "extension bar" when Chrome entirely abandoned their "toolstrip", which was in the same location? Is this "extension bar" going to be superior to Chrome's (i.e. being able to drag items within the bar and from the bar to the other toolbars)?

I should note that the plan for the extension bar is not necessarily mutually exclusive with a small area at the bottom of the screen that shows the location the user is about to navigate to (similar to chrome). However I think using the location bar has a few advantages if we can figure out all of the various problems, including: -pages trying to spoof their URL -focused links out of view -etc >when Chrome >entirely abandoned their "toolstrip", which was in the same location? Is this >"extension bar" going to be superior to Chrome's (i.e. being able to drag items >within the bar and from the bar to the other toolbars)? I'm actually not familiar with the toolstrip they had, but the extension bar should have all of the same customization abilities as other tool bars in Firefox, and (hopefully) it's position will be customizable as well.

From the standpoint of a user... I personally like the tooltip-like content overlay/popup at the bottom of the window. This would allow for Firefox to maintain some visual consistency by making the same information available in a similar location/fashion. Doing this would also fulfill Bug 586718, by letting connection status, extensions, and webpages display their 'status' text in a sane manor. Instead of specifically hooking into mousing over links, it could be made into a generic call (i.e. window.status). Then then popup would show when the status was changed, and hide after a certain (configurable) timeout. I do not think the general user would appreciate this being done in the URL bar. I know I personally would find it unexpected and probably confusing. Plus, it seems like this is something that could be abused (i.e. programmatically keeping a link focused). If a user does want the link displayed in the URL bar, they have the option of using an extension. Personally, I use URL Tooltip, which allows me to see the URL and associated title/alt attribute (of the link or parent element). I personally find this to be the best solution because it puts the desired information right where the user's attention already is. (In reply to comment #5) > True, but tooltips are a bit slower and aren't an option for keyboard users. > It's good to have duplication there. Why not? Showing a tooltip, if one is defined or available, when an element is given keyboard focus, sounds like a good accessibility improvement for both content and UI. (In reply to comment #7) > The popup wouldn't even have to be higher, it could just overlay the bar and > fade away when you actually want to use the bar. Why not have the popup be aligned to the bottom of the content frame? That way it would not interfere with the find bar, or any other toolbars an extension might add down there. This would also allow it to be visible when in full screen mode.

User opinion: displaying hyperlink URLs in the urlbar is crazy idea. If it happens so, I will stay on the old Fx versions without this feature until someone makes an extension to fix this behavior. My opinion is that a Hyperlink URLs Bar (or HUB) (let's call it so) should be hidden until user focuses on the url on the page, and when it happens - HUB should appear at bottom (just like in Chrome). In my opinion - it's the best behavior ever possible.

We may still end up going with this approach, but initially the UX team would like to try out bug 587908 since that has a stronger natural mapping and teachers users to look to consistently look to the location bar for identity information. (the downside though is that it might be visually kind of noisy since there is higher contrast in a white text field).

Should this not be a resolved duplicate of bug 587908

No, it's not a duplicate, but it may be wontfix. In other news, this apparently became parity-IE now as well.

This bug is now WONTFIX unless we want to have an option to switch between this and the now implemented bug 587908. Making it an option might be a good idea, but it also might be a better idea for an addon, so I don't know. Because of all the other applications doing this I think a built-in option may be warranted.

To quote recent precedent: The tabs-on-top feature was turned on by default, but has a quick and simple option to switch it back to tabs-on-bottom. Now that we have a link-URL-on-top mode, I think we should also have a link-URL-on-bottom mode with a simple option to switch it back.

Bugs that could benefit from this one: Bug 585445 - Make App Tabs chromeless Bug 243468 - Improved form upload manager/progress display Bug 314673 - Link locations not shown in full-screen mode

I'm going to include my UX arguments against putting ghost URLs in the location bar here, since my bug was duped: 1) as my mouse moves around the screen, the changing location bar is distracting to users 2) users are trained to see notifications near the top of the window, the location bar being under the tab makes me think the page itself is changing 3) the url tooltips are right-justified, making the url hard to visually scan as the start x-location changes based on URL length 4) small windows means my current URL is completely obscured as I move my mouse 5) dimmed text make it harder to read than it was in the status bar Please just do what Chrome does: display the status bar only when user is hovering over a link.

I second Jeff's opinion.I haven't seen how Chrome does it, but I think that the link should still be displayed in the status bar. If people need real estate, then show status bar only on hover over link seems perfect. If people still disagree, then please make it an option (same way the menu bar and tabs on top is) instead of starting a flame war over what should be done and which way is better. On other notes... after latest nightly update I see only 'Done' in status bar no matter if I hover my mouse over links or not. Does enyone else have this or am I the only one?

@klonos - this is the recent change that I'm complaining about in Bug 597191 - the hovered URL shows up in the _Location Bar_ of all places (overtop my existing URL). Also, I have to completely disagree with the 'just make it a configurable option'. Make most UX decisions for your users. Users will vote with their feet (they'll use your product or they'll abandon it for something better).

(In reply to comment #19) > 2) users are trained to see notifications near the top of the window, This is not exact for Oses at least : Windows notifications and IE9 are on bottom ; On OSX Growl is easily set to any corner ; On Linux the notification area can be catch and be shown anywhere else. ;-)

Dao's created an add-on for the people against the url in location bar. http://en.design-noir.de/mozilla/linktarget-display/ That's all, folks.

I would greatly regret if this bug would get WONTFIX'ed and the only option for dissatisfied would be installing an addon. As far as I remember, bug 587908 was like "let's try it, that what betas are for" and not the ultimate decision. Therefore please do not make it so, and give beta-testers choice and UX team ability to gather data about real users' preference on this. I think the wave of forum posts and blog articles about "how can we get rid of this feature" already matters something. Let's not stick with failed experiment just because too much efforts were put into it.

So this bug is now getting patched somehow, right? /be

FYI, Bug 628654 is talking about not using native OS windows for the overlay. This is going to be a problem if it's also going to be used for the hovered link (aka like Chrome), since some websites put content at the bottom of the window (Facebook's chat box comes to mind). Chrome moves the overlay out of the way if your mouse pointer goes overtop of it. Of course Bug 628654 also mentions "no scope creep" so I'm creeping along over here :)

(In reply to comment #27) > FYI, Bug 628654 is talking about not using native OS windows for the overlay. > This is going to be a problem if it's also going to be used for the hovered > link (aka like Chrome), since some websites put content at the bottom of the > window (Facebook's chat box comes to mind). Chrome moves the overlay out of > the way if your mouse pointer goes overtop of it. Still, native OS windows aren't absolutely necessary. When Chrome's windows are maximized, it moves the overlay to the right side of the window, instead of downward. We can do that. I don't see any need for a separate native window at all to accomplish this.

Can we not get a pref for this? Even if it's a hidden one for now?

Let me tell outright that I complained a lot on the removal of the status bar and on the fixing of bug 587908 at first. But now I've really grown to like the fact that all *location* information is in the *location* bar. I'd say focus should go on fixing all dependencies of bug 587908 instead of throwing away all the good work done there. The ones I think are specially urgent are bug 596644 and bug 596802 Why [parity-*] is even a reason? The current approach is better IMHO and if bug 588270 gets fixed then we're golden. It would be easier for me to tell mom and grandma "Just look up here, it'd tell you where you're going". My 2¢ and sorry if it classifies as bug spam =(

updated patch, in case anyone is interested. mostly code removal, only tested on Linux so far.

(In reply to comment #26) > So this bug is now getting patched somehow, right? > > /be Not having been invited to the private email thread, I don't know the current plan. If this bug is part of the plan, the blocking state should probably reflect that, and then I can request review on the patch.

Quick question about the proposed functionality: are we going to display only loading messages, or both loading and link target?

(In reply to comment #33) > Quick question about the proposed functionality: are we going to display only > loading messages, or both loading and link target? This bug would appear to be about the link target. Bug 628654 was about the loading messages.

I look forward to landing this before shipping Firefox 4, because looking on the opposite site of screen to see only link was a wrong idea. Bottom left side of the screen is a far more intuitive than looking on upper right, because ppl eyes in browsing sites look mostly on down-left side of the screen like for example this bug tracker. Also it will work in fullscreen mode, not like this integrated in location bar... :)

(In reply to comment #35) > I look forward to landing this before shipping Firefox 4, > because looking on the opposite site of screen to see only link was a wrong > idea. > Bottom left side of the screen is a far more intuitive than looking on upper > right, because ppl eyes in browsing sites look mostly on down-left side of the > screen like for example this bug tracker. > Also it will work in fullscreen mode, not like this integrated in location > bar... :) People in America think driving on the left side of the street is wrong while people in the UK believe driving on the right side of the street is wrong, yet both manage to adapt.

(In reply to comment #36) > People in America think driving on the left side of the street is wrong while > people in the UK believe driving on the right side of the street is wrong, yet > both manage to adapt. Most sites are left arranged, like I said before in example. And when you read sth and want to fast check link, you don't want to look somewhere far away to check it (less eye job). Simple. Of course you can adopt to everything, but will it be useful ? And you don't get link info in fullscreen, like I said before.

(In reply to comment #37) > (In reply to comment #36) > And when you read sth and want to fast check link, you don't want to look > somewhere far away to check it (less eye job). Simple. > Of course you can adopt to everything, but will it be useful ? > > And you don't get link info in fullscreen, like I said before. It takes no more effort to look slightly up than looking slightly down. Looking down to find the link target in a Status Bar is a conditioned action. Those who use browsers for the first time does not know where to look for such info until they learn that its there and train themselves to look for it there. However, those who have trained themselves to look for it there already often have a problem with the changed position until they re-train themselves to look for it elsewhere. This is the current situation with the present Link Target location. The status messages as simple as they are now, should have been placed in the same place as the current link target. This prevents having to seek back to the bottom of the screen for the info. However, I do agree about the Full Screen mode needing this functionality. I also think that the link target should be at the top of the screen where a location bar is expected in that mode and styled to match the current theme. Or perhaps using the actual location bar as an overlay with the link target shown for consistency.

While I don't agree with the other commenter's supposition that most text is left aligned on the web (if anything, I would tend to think it's centered by most site designs), I've also never been able to understand the rationale from comment 38 that states the URL info just simply should have been in the URL bar, as if that's inarguable. It certainly depends entirely on the individual user's usage pattern as to where their eyes are most likely to be when hovering over a link. For myself, and most others I've ever observed as they use the browser, they are scrolling down the page slowly, with the mouse often position near the bottom of the page, in the section that they're currently reading. It's then that they hover over a link as they read it... with the mouse toward the bottom of the page. At this point, since you've just been looking at the mouse as you highlight the word, it's obvious (for these cases, myself included) that it's easier to redirect your eyes slightly down to the AddOn Bar location to see the link target... not all the way back up to the top of the browser (don't get me started on the fact that there seems to no longer be any intent to set the link target info in the Awesome Bar to start at a FIXED left aligned location. As it is now, the beginning of the URL jumps all over the place based on the length of the target link. If in fact it's simply a matter of "training" your eyes to move to a new location, how is the user supposed to do that when their eyes constantly have to adjust to a new horizontal location to start reading from in the Awesome Bar?). Anyway, just my, and I assume at least SOME others', rationale for why the link target is simpler to use at the bottom.

Yes the moving start position of the current link target implementation is a huge eyesore for me and I really miss being able to see where my links are going in fullscreen mode. Also the links that I hover over are almost always closer to the bottom right than the top left. Currently I have to move my eyes a lot more to see the target. If the link target was displayed with the status overlay there's less distance for your eyes to traverse.

Nothing in comment 38 is explicitly stated as inarguable. Comment 38 states that the recently re-inclusion of the status messages provided by bug 628654 be placed in the same area of the Location bar as the current Link Target location. Comment 38 also makes a suggestion about the Link Target in Full Screen mode be placed in a similar location to the current Link Target location in normal mode. Comment 38 does not state that "URL info just simply should have been in the URL bar". That is something completely fabricated by Comment 39. As for the supposition on observed behavior, Links on a page are never in a fixed position for every site. Left to Right reading patterns on typical articles puts the progressing page links at the bottom right location obviously. However for every other site, this is not the case. Every time a user wants to see the target of a link, eye scanning position has to reset. Placement in the top of the browser puts the messaging in a high usage location and at a natural eye level. (Also because of the eye scan reset, the "jumping" of link target is less of an issue because it's always fixed to the right of the Location Bar as an anchor point. Long URLs still need to be scanned no matter the position in the browser.) Heat maps of common web page layouts in independent studies, often called the "F-pattern" also places this information closer to where a user's eyes are most likely to be on a given web page. If an individual's usage pattern truly changes anything, then there's certainly more to the observed behavior than currently stated in Comment 39.

Apologies, it was somewhat construed from this "The status messages as simple as they are now, should have been placed in the same place as the current link target." It was the "should have been" that led me to make that incorrect statement (likewise, rereading it, it was more in reference to the status messages, not URL targets). That said, I still take issue with "Long URLs still need to be scanned no matter the position in the browser". Yes, of course the user has to read the URL in order to "scan" it, but there's a vast difference between moving your eyes to a fixed point (ie - the far left at the bottom) and then naturally reading left to right as you normally would, vs moving your eyes up to the top to a fixed "area/zone" and then backtracking an indeterminate amount to the left until you find the start of the URL... in order to then read left to right as usual. I can't understand how anyone can defend Mozilla's decision to drop the priority of implementing a fixed location for the start of the URL target displays. "Less of an issue" doesn't mean good design. Judging by the number of introduced bugs since the switch, placing the URL target info in the limited space of the AwesomeBar only accomplished having to deal with a ton of edge cases (how best to position the start of the URL, how to deal with long links, which portion of the link becomes worthy of display, etc), that were never (or much more rarely, in any event) necessary prior. The other thing that somewhat confuses me though is that you seem to agree in part, "Left to Right reading patterns on typical articles puts the progressing page links at the bottom right location obviously", but then go on to simply say, "However for every other site, this is not the case". What accounts for the other sites? More importantly, would the other sites represent a majority over the typical reading of formatted articles that users do throughout the day (facebook for one)? Would it not have made more sense to work for the majority in the goal of usability?

(In reply to comment #42) > That said, I still take issue with "Long URLs still need to be scanned no > matter the position in the browser". Yes, of course the user has to read the > URL in order to "scan" it, but there's a vast difference between moving your > eyes to a fixed point (ie - the far left at the bottom) and then naturally > reading left to right as you normally would, vs moving your eyes up to the top > to a fixed "area/zone" and then backtracking an indeterminate amount to the > left until you find the start of the URL... in order to then read left to right > as usual. I can't understand how anyone can defend Mozilla's decision to drop > the priority of implementing a fixed location for the start of the URL target > displays. "Less of an issue" doesn't mean good design. Judging by the number of > introduced bugs since the switch, placing the URL target info in the limited > space of the AwesomeBar only accomplished having to deal with a ton of edge > cases (how best to position the start of the URL, how to deal with long links, > which portion of the link becomes worthy of display, etc), that were never (or > much more rarely, in any event) necessary prior. A number of edge case bugs are always an issue that has to be handled because of new features and designs. This has been true throughout the history of Mozilla's browsers. Also since this is one of many new directions for browsers, unexpected issues are bound to crop up. I mentioned before, the position of the Link Target is fixed, just at the right instead of the left and still gives a solid and recognizable position for the target. This position is no different than scanning back and forth for the correct tab on a full tab bar. For someone comparing links to the current location, this is an optimal position. "Backtracking an indeterminate amount" is only a concern for long link targets, but the link target is limited to about 100 characters like many other browsers currently and still has to be scanned. Especially if the info is valuable to the user. Now whether or not its good or bad design depends on whether or not one can judge it without conditioned browser usage behavior diminishing objectivity. > > The other thing that somewhat confuses me though is that you seem to agree in > part, "Left to Right reading patterns on typical articles puts the progressing > page links at the bottom right location obviously", but then go on to simply > say, "However for every other site, this is not the case". What accounts for > the other sites? More importantly, would the other sites represent a majority > over the typical reading of formatted articles that users do throughout the day > (facebook for one)? Would it not have made more sense to work for the majority > in the goal of usability? Because the "F-pattern" is common throughout many websites, the majority in the goal of usability is at the top of the screen, not the bottom as not many progress that far down often. Typical articles are the exception to the rule for those who read all the way through. The eye scan places progressing links toward the bottom right of an article as I mentioned before. This makes it easier to find the progressing link. But in order to see the link target, the eye still has to reset. Websites like a retailer website tend to have a more scatter shot layout that somewhat defies the pattern. But the scan pattern is still present. For Facebook, the "F-pattern" is very strong. Example of a typical Facebook page heat map: http://www.youtube.com/watch?v=gu46oeqUIyg

Something like Bug 629304 should also be considered while fixing this.

This would also work better with chromeless app tabs (bug 585445) than displaying the URL in the location bar.

(In reply to comment #43) > I mentioned before, the position of the Link Target is fixed, just at the right > instead of the left and still gives a solid and recognizable position for the > target. This position is no different than scanning back and forth for the > correct tab on a full tab bar. For someone comparing links to the current > location, this is an optimal position. "Backtracking an indeterminate amount" > is only a concern for long link targets, but the link target is limited to > about 100 characters like many other browsers currently and still has to be > scanned. Especially if the info is valuable to the user. The fact that the location of the URL target display in the AwesomeBar is "the optimal location" in order to compare to the existing URL is a good point, one that I'm not sure has ever really been brought up very often. Thanks for pointing that one out. Does help in understanding the rationale of the larger change. Again, I could deal much better with the URL target showing up in the AwesomeBar if it weren't for the non-fixed starting point. You state that the location of the info is fixed, and yes, it is insomuch as it's always on the right-hand side of the bar. But the more important "starting reading position" is NOT fixed... and that's the problem. You argue that it's no different than when you have to scan a row of tabs in order to find the right one. But I fail to see how an argument of (and obviously not quoting) 'there is work involved in doing this, so it's okay that there now needs to be work involved in doing that' (lets agree that calling it 'work' is going too far, but just to make a point) is valid. Looking for a URL target and looking for a tab you want to go to are mutually exclusive operations. The fact that the "info is valuable to the user" doesn't justify making it harder for them to easily read a URL. BECAUSE the user will work for something doesn't mean they should have to. What bothers me is that this would all be a moot point if one of the original dependent bugs for URL in the AwesomeBar hadn't been totally abandoned for inclusion in 4.0. Still don't understand that move, in light of other blockers that have a far lesser UI impact to the user. Feel free to respond if you'd like, but I'm sure others are tired of reading this, so this will be the last post I'll make in the bug on the topic. I appreciate your responses though, and will follow-up directly in email from here on out if need be.

updated to tip

Nothing has changed since bsmedberg marked this blocking-, and nobody has said why it should block now. If you feel it should be blocking, at the very least, provide a rational as to why it should block now and what has changed from before.

(In reply to comment #46) It doesn't matter anymore regardless of what anyone says here. The project leaders have decided to regress the functionality near its previous state.

>Nothing has changed since bsmedberg marked this blocking-, and nobody has said >why it should block now. I would like to also renominate this for blocking since bug 628654 recently landed. Users will likely expect URL link hover to appear in the same location as extended loading status, due to both external consistency with other products, and internal consistency with previous versions of Firefox. The UX team still thinks that the location bar provides a better location for both pieces of information (see our extended discussion elsewhere). But since we have moved some of the information to a new location, the simplest approach (in terms of interface) for this release is to move link hover to the new location as well. Sometimes triage and compromise can break apart a design into disjoint parts, but I think there's a pretty clear precedent for these two types of information being displayed in the same location.

Do you show the URL in the addon bar if enabled with this patch?

(In reply to comment #51) > Do you show the URL in the addon bar if enabled with this patch? No, that would be bug 629304.

So, just to be completely clear, we're not even leaving the in-address-bar hover link in for certain modes or as an option; this is a full replacement (late in the Firefox 4.0 cycle)? If this is the case, are we going to add another beta to get full coverage? This is a big UI change. For the record, I was initially against the in-address-bar hover link but I've come to like the idea. The A -> B imagery is good for less computer savvy users, though the space constraint and address-bar-less modes are issues. I'm not against a bubble at the bottom similar to the new status text, especially because it will fix a few problems, though I wish we could've decided on this earlier. ;)

Comment 33 should go in the d-a-f thread. We're doing another beta but we don't need super-long to user-test something old that's new again. Code quality testing is an auditing step we're going to cover in betas and RCs. /be

So the most distinctive new feature I've grown to love from Minefield A > B in the location bar (bug 587908) is going away to make Firefox more Chromium like? If people like Chromium behavior, let them go use Chromium. This is a change and an improvement and it's bound to cause discomfort at first but it is an improvement in the long run. Anything that can be done for bug 587908 to stick or would it be left out for Firefox 5.x?

"If people like Chromium behavior, let them go use Chromium." Good lord... if this is the attitude that high up developers on Firefox are going to have, then Firefox may very well be doomed. Shouldn't it instead be "People seem to like Chromium... what do they like about Chromium?" As seen by the MANY MANY complaints on input.mozilla about the status message and URL hover changes, I think the "improvement" factor is up for debate anyway. A change, sure, but one with pretty dubious benefit given the amount of issues it seems to have created. If a mature implementation can be implemented for FF5, I'm more than willing to give it a shot. But given the state of things at this point in time for FF4, I can't see how any other decision could've been made it it was to ship sometime this month.

Tim: alex is not a high up developer (singular) on Firefox. You need to read more carefully before generalizing and blaming whole groups (I don't buy collective guilt in general). And take it to d-a-f, this bug is not the place for chatter! /be

It would be great if we can get reviews quickly turned around for inclusion in beta 11.

Will there be option to continue using hyperlink URLs in the location bar, if this would land?

We are we removing the code here, as opposed to putting it behind a pref? As I mentioned in bug 628654 comment 0 we will want to be able to make the location pref-able, I suspect.

Couldn't this bug be option? Similar to Tabs-on-top (default) and Tabs below location bar (3.6)? Have hyperlinks URLs in the location bar as default and then let users have an option to move it "bottom of window" a la statusbar functionality? For me this is getting very confusing. Is there an official statement from Mozilla regarding location bar and status info, how it will be Firefox 4 final?

Michael: no need to ask the same question over and over. Gavin and I chatted on irc.mozilla.org, and he's a little concerned about leaving this much code in the tree if we've no intention to use it. I'm going to write to dev-apps-firefox later tonight outlining a plan in which we can hopefully find a compromise which sees the lower-left overlay being used by default, and the location bar being used as an option, though I suspect that at this late point in the release, that represents more work and risk than we want. For now, I must agree with Gavin; it's cleanest to remove the code until there's need to add it back in. :/

Thank you for your answer and clarification. I don't follow irc.mozilla.org so I missed that conversation. Hope you will be able can find a compromise. I won't bring this up again. Sorry if I'm bothering you guys, just learning how use these different channels of communication about Firefox development. I care about Firefox and understand the problems you are facing, even though I sometimes have my own preference (see earlier comment and bug 629915). Keep up the good work!

Comment on attachment 508325 [details] [diff] [review] patch >diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js >+var LinkTargetDisplay = { Can you rely on the fact that clearTimeout never throws to remove some of the _timer checking/setting-to-0? It's kind of odd for this to be split out into separate objects that call into each other - why not just implement this all in XULBrowserWindow? >+ update: function () { This seems to regress bug 606304... >+ handleEvent: function (event) { >+ switch (event.type) { >+ case "mousemove": >+ if (!this._isVisible) >+ this._showDelayed(); I don't really understand what this is trying to do. >diff --git a/browser/base/content/urlbarBindings.xml b/browser/base/content/urlbarBindings.xml You forgot to remove a call to _hideOverLink in the urlbar binding focus handler. >diff --git a/browser/themes/gnomestripe/browser/browser.css b/browser/themes/gnomestripe/browser/browser.css >-.urlbar-frontcap-and-textbox { >+.urlbar-textbox-container { > -moz-appearance: none; > } (unrelated: does this actually affect all children? I would not have expected that) > #urlbar > toolbarbutton { >- margin: -2px; >+ margin: -1px; >diff --git a/browser/themes/winstripe/browser/browser.css b/browser/themes/winstripe/browser/browser.css > #urlbar > toolbarbutton { >+ margin: -2px; >+ -moz-margin-start: 0; Why these changes?

Why not have the mouse-over URL view optional with preferences settings for where the user wants to see it? Some users don't care about the URL, some do -- some prefer it in the location bar, some on the status bar, and some yet as Chrome's "only when in use" mouse-over bar. Personally, I find Chrome's method interesting, but yet annoying when a page auto-updates and an URL appears for no good reason on the screen. I've opted for a plugin called Status4Ever to restore my faithful status bar. Surely the "right" way to do this is a matter of opinion & could be left to the USER to decide? -- With a default set to whatever the current trend is, of course.

kingramze: you must be new around here :-/. Please take it to dev.apps.firefox: https://groups.google.com/forum/?fromgroups#!forum/mozilla.dev.apps.firefox No, we do not maintain optional UI that won't be tested by the vast majority of users because it is non-default. Add-ons can handle that kind of optionality much better. This point among others was covered way back in 2003: http://www-archive.mozilla.org/roadmap/roadmap-02-Apr-2003.html /be

(In reply to comment #64) > Can you rely on the fact that clearTimeout never throws to remove some of the > _timer checking/setting-to-0? Yeah. > It's kind of odd for this to be split out into separate objects that call into > each other - why not just implement this all in XULBrowserWindow? I think this would end up being a bit messy, unless I keep the methods contained in a child object, though even then it would make it harder to skim the "core" XULBrowserWindow stuff... > >+ update: function () { > > This seems to regress bug 606304... I've only remotely followed bug 606304. I'm not sure I'm using the same pattern and the same solution applies. I can look into it, but I'd suggest filing a followup bug on it if it's the last remaining issue. > >+ handleEvent: function (event) { > >+ switch (event.type) { > >+ case "mousemove": > >+ if (!this._isVisible) > >+ this._showDelayed(); > > I don't really understand what this is trying to do. It resets the timer when hovering over a link, so that the popup is only displayed when the mouse rests. (I think the delay should probably be longer, though.) If the popup is already there, waiting would be pointless, hence the _isVisible check. > >diff --git a/browser/themes/gnomestripe/browser/browser.css b/browser/themes/gnomestripe/browser/browser.css > > >-.urlbar-frontcap-and-textbox { > >+.urlbar-textbox-container { > > -moz-appearance: none; > > } > > (unrelated: does this actually affect all children? I would not have expected > that) What's "this"? > > #urlbar > toolbarbutton { > > >- margin: -2px; > >+ margin: -1px; > > >diff --git a/browser/themes/winstripe/browser/browser.css b/browser/themes/winstripe/browser/browser.css > > > #urlbar > toolbarbutton { > > >+ margin: -2px; > >+ -moz-margin-start: 0; > > Why these changes? Both are reverting changes from bug 587908. I think the gnomestripe change was unrelated to the rest of that bug. I'll double-check if it makes sense on its own. The winstripe change is needed to keep the buttons pushed to the border.

I reorganized the new code a bit. Hopefully it's more understandable this way. It's still in a dedicated object. I dropped that one change in gnomestripe, as it's unrelated. I don't think I can use setInterval here.

I hate to nitpick, but I just installed the latest hourly that has this built into it (Built from http://hg.mozilla.org/mozilla-central/rev/8c8a1ef2a816) and when you hover over a link and then move your mouse, for the briefest moment, you can see this as the link disappears from the lower left corner of the browser: http://i.imgur.com/fmyMj.png

(In reply to comment #70) > I hate to nitpick, but I just installed the latest hourly that has this built > into it (Built from http://hg.mozilla.org/mozilla-central/rev/8c8a1ef2a816) and > when you hover over a link and then move your mouse, for the briefest moment, > you can see this as the link disappears from the lower left corner of the > browser: > > http://i.imgur.com/fmyMj.png Bug 629898 should fix this. Please do nitpick and file new bugs as needed.

Any reason why we're not displaying the http or https in the link target? I feel that this is pretty valuable information on encryption that's being left out.

(In reply to comment #72) I am seeing https but not http, and i want it this way.

Gah this is so much like chrome. This is pretty annoying behavior, because the start of the domain name is now at a different place between http and https. There's really no reason to do this. It's inconsistent.

All of this needs to be placed back in the URL Bar. The prgress looks better in the URL bar as does everything else.

Bug 631428 When the add-on bar is open, it doesn't look right to be taking up content space when there so much empty chrome right below it. Forgetting for the moment the history of these wanderings, if you compare 3.6 to 4.0, it just looks like link preview and progress messages have been arbitrarily moved out of the status bar (now add-on bar) and into content, for no discernible reason. The overlay makes sense when the status bar (add-on bar) is hidden, but not when it's visible.

I feel this changed behavior is too intrusive. Hovering mouse on link is more frequent than loading pages. It is even when using modern Web Apps. And also, Is showing information at bottom hard to move line of eyes? At this moment, after deleted status bar, lot of information are placed on top area of window. I thought it is unuseful that moving eyes from top-end to bottom-end of window.

The behavior caused by this "Fix" is annoying to say the least. Why fix something that is not broken. Change for the sake of change is not productive. The status text needs to be placed back in the URL Bar. To see that white box pop up every time I hover over a link is very annoying and bothersome.

"Change for the sake of change is not productive." MANY said the same thing about the move to the URL bar in the first place :( Given the time-frame until release (and the lingering issues with display in the URL bar: no left alignment, no solid determination of what's the "important" information to show), putting it back to the old location I think is a solid decision for the time being. I'm all for revisiting it with proper time allotted for FF5 though.

(In reply to comment #80) > "Change for the sake of change is not productive." > > MANY said the same thing about the move to the URL bar in the first place :( And yet there was evidence to the contrary. It was actually a well researched and thought out piece of redesign. The same can't be said for this. That said, it's important to note that a decision has been made and no amount of whining in this bug will get it undone. We can only hope someone comes up with an extension/userchome/stylish soon.

(In reply to comment #81) > it's important to note that a decision has been made and no amount of whining > in this bug will get it undone Bugzilla is not a place for "whining". It will not be effective in this or any bug for any side of any issue because it is inappropriate activity for Bugzilla. Blog are cheap or free. Go whine elsewhere. All of you. Consider this a warning. I have no qualms about disabling Bugzilla accounts (just ask the handful of people that've seen it happen in the last few days) and if you cannot comport yourselves appropriately in this critical Mozilla workplace, I will bring the hammer down.

(In reply to comment #74) > This is pretty annoying behavior, because the start of the domain name is now > at a different place between http and https. Dao, is there a bug on this? It needs to be fixed. /be

Benjamin filed bug 631497.

(In reply to comment #82) > Consider this a warning. I have no qualms about disabling Bugzilla accounts > (just ask the handful of people that've seen it happen in the last few days) > and if you cannot comport yourselves appropriately in this critical Mozilla > workplace, I will bring the hammer down. To clarify what Asa said, comporting yourselves appropriately means following bugzilla etiquette: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

v. Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre Mozilla/5.0 (Windows NT 6.0; WOW64; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre

Please note Bug 631812 for themeing issues caused by this patch.

When a page is loading, hovered links are not displayed. This works in Google Chrome and should be fixed IMO.

(In reply to comment #88) > When a page is loading, hovered links are not displayed. Links are prioritized over the loading status, but this only works if the front-end actually gets notified about them. This may not happen when interacting with the page is suppressed or when the browser is generally unresponsive.

why can't we have link URLs be displayed inside of add-on bar (if it is enabled)? why waste extra screen space?

I hate this so much! Displaying in the location bar was so much cooler and easier to look at! This also has problems interacting with the networking messages showing up in that popup bar.

Display url in location bar is better and cooler. This patch just copy idea from googe chrome.

In Windows, does this work exactly like a system tooltip and obey registry settings (like delay) for tooltips?

(In reply to comment #94) > In Windows, does this work exactly like a system tooltip and obey registry > settings (like delay) for tooltips? No. The delay is controlled by the browser.overlink-delay pref. See also bug 632365.

Why is the URL truncated at the half of the Screen? There is much more space left and i would expect to see the whole URL or at least as much as possible. Truncating at the end makes it hard to realize the URLs target. It would be better to truncate in the middle of the URL. Is it better to open a new Bug for this? If not i would appreciate if someone reopens this.

(In reply to comment #96) > Truncating at the end makes it hard to realize the URLs target. It would be > better to truncate in the middle of the URL. see also bug 596644

(In reply to comment #97) > see also bug 596644 Thank you for the hint, i still have problems with the search to find what i am looking for.

I agree with Christoph. We should use all of visible screen space, because long links exceeding half of the screen are not fully shown now.

I think the main reason for truncating to half the screen is because when you mouse over the overlay it shifts to the other side of the screen. If the overlay was any bigger than half, then you run the risk of the overlay still blocking the mouse even though it shifted out of the way. I suggest only truncating when the mouse is over the overlay, and not truncating in all other cases.

I have to question the decision to place the popup on the right side of the screen. When hovering over multiple links in a row, all of the text moves, even when the stem is the same. These things are left-justified for a reason. The default should be on the left side, like chrome, with movement to the right when the cursor is blocking it. IIRC There was a bug regarding left justification when the URL was in the URLbar as well. This problem has not changed just because the link URL has been moved out of the URLbar. Additionally, the current chrome-like implementation suffers the same flaw chrome's does... mainly the things it has in common with the <blink> tag. Meanwhile, it actually makes the situation worse when the addon bar is open; more vertical space is wasted vs. 3.6.

(In reply to comment #96) > Why is the URL truncated at the half of the Screen? There is much more space > left and i would expect to see the whole URL or at least as much as possible. See bug 632634.

(In reply to comment #101) > I have to question the decision to place the popup on the right side of the > screen. The popup should show up at the bottom left corner, unless the mouse is in that area (in which case it moves to the bottom right. If you're seeing something different, please file a bug.

(In reply to comment #100) > I think the main reason for truncating to half the screen is because when you > mouse over the overlay it shifts to the other side of the screen. If the > overlay was any bigger than half, then you run the risk of the overlay still > blocking the mouse even though it shifted out of the way. > > I suggest only truncating when the mouse is over the overlay, and not > truncating in all other cases. we could move it to the upper edge of content area in that case.

Note that this is responsible for a 10% tp4 hit on windows xp (we didn't catch it because our tp4 was not actually measuring page load times with browser chrome enabled). See bug 655930 comment 30 for details.

(In reply to comment #105) > Note that this is responsible for a 10% tp4 hit on windows xp (we didn't > catch it because our tp4 was not actually measuring page load times with > browser chrome enabled). See bug 655930 comment 30 for details. filed bug 658852

guys, please fix any blocking bugs for #587908, and then only use this fallback here when in fullscreen mode. it was the best new idea in ui design which i saw in quite a long time and removing it for this one (which is 1. a ripoff of chromium’s way to do it and 2. works worse) is just a joke. i really don’t get the way decisions are made here: i am subscribed to bug 587908, and i want to see that it is replaced THERE. before they are made. so that i can tell you why i love the way it is done there, and why i don’t like the way it is done here. i call this a regerssion.

>i really don’t get the way decisions are made here yeah that's a fair question. The decision making process is governed by our module owner system: https://wiki.mozilla.org/Modules In this specific case, the call was actually made at the highest level (http://www.mozilla.org/about/roles.html#ultimate-decision-makers ). If I remember correctly the primary concern was that the interface being proposed in bug 587908 didn't support displaying third party server loading status. The UX team is planning on continuing to work on a solution that leverages the location bar, with the intention of it landing on nightly builds in a complete state (as opposed to landing it again in an incomplete state). The decision was less about which interface was better in an ideal world, and more about which code was currently finished as we rapidly approached shipping Firefox 4.

(In reply to comment #108) > >i really don’t get the way decisions are made here > yeah that's a fair question. The decision making process is governed by … thanks for that insight! > The UX team is planning on continuing to work on a solution that leverages > the location bar, … so it’s planned to revert to a better-working version of the link-target-in-location-bar some day? and what exactly didn’t work? the addon “link location bar” works flawlessly for me, except in fullscreen mode (where i seldom use links, anyway) and the hover-bar approach could still be used as “fallback” in fullsceen mode.

Could you please stop treating this closed bug as a discussion forum? Thanks!

(In reply to comment #110) > Could you please stop treating this closed bug as a discussion forum? Thanks! as soon as i’ve got an answer for these two small, *on-topic* questions :) sorry if you feel spammed, but you can unsubscribe from this bug whenever you want.

I own bug. I can't unsubscribe. And no, your questions don't belong here.

@flying sheep: Nothing is on-topic in a verified fixed bug with no regression (within the confines of the bug itself). Please don't misuse the openness of this system. File a new bug or start a discussion in the groups for any followups, extensions, counter-proposals, or future plans/ideas. Just mark it new bugs dependent of this one or link to any discussion briefly and anyone who chooses to participate in the discussion will do so. Your inquiry is legitimate, but following the (admittedly loosely stated, sometimes) expected protocols here is the best way to get heard and not contribute to the din of messages that people who are subscribed to a large number of bugs and/or components get.

> I own bug. Oops, I should read what I'm writing before posting it. I was going to say that I own this bug. (See the "Assigned To" field.)

OK, thanks, filed bug 664973. please tell me there what arguments I missed, etc.