Closed Bug 587908 Opened 14 years ago Closed 14 years ago

On hyperlink hover, display the target in the location bar

Categories

(Firefox :: Address Bar, defect)

Product:
Firefox
Component:
Address Bar
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 4.0b7
Tracking Flags:
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: faaborg, Assigned: adw)

References

Details

Attachments

(5 files, 21 obsolete files)

Hyperlink Hover in the Location Bar Mockup
77.13 KB, image/png
Details
Integration with the identity button: proposal mockup
110.77 KB, image/png
Details
for check-in patch
32.16 KB, patch
Details | Diff | Splinter Review
URL spoof test case 1
573 bytes, text/html
Details
URL spoof test case 3
751 bytes, text/html
Details
This bug is an alternative to bug 541656, and covers displaying the target of the hovered hyperlink on the right side of the location bar in grey text. We should add a clear differentiators line, and perhaps the text "Go to:" before the URL. URL of the target should appear in disabled greytext.
Blocks: 579521
Perhaps more right aligned? I really like the > with the white fade on the left side of it.
Blocks: 574688
Too busy/unclear. Much prefer Chrome's bottom of window system.
For what it's worth, I like this idea. It makes sense for the the target URL to be displayed in the URL bar. We're still in beta, so we can get feedback from users about their view on it, and if the majority don't like it, we can change it.
I’d like to point out one benefit this approach could have over others. Say you hover over a link and want to edit that URL. With Fission installed, all I have to do is hit Ctrl+L and that URL is instantly copied over to the location bar and selected, ready to be edited and used. I make use this discovery quite frequently, and it’s become my favourite little feature. This is really a consequence of the conceptual purity gained by displaying all URLs in the location bar, always editable. You don’t get this purity with the other approaches.
This blocks the status bar replacement in bug 574688, so is also blocking+.
blocking2.0: --- → beta6+
Version: unspecified → Trunk
I have to say that I am not a fan for this for a number of reasons: - This makes the location bar too busy visually. A lot of stuff is already being added to the location bar, I don't think we really need more. - Makes it difficult to compare the current URL to the link. especially if it is intended that the current URL gets truncated. - Makes keyboard shortcuts, that affect the location bar, ambiguous (i.e. site identity, edit, etc). Should they act on the current URL or the link URL? - Potential to be visually distracting. Is there going to be a timeout before the URL is going to be displayed (like a tooltip)? I don't want the location bar spazzing out if I mouse across a forum index or link aggregate site. - When displaying a link target, icons on the right side of the location bar (bookmarks, feed, etc) feel out of place or miss-associated... Unless the plan is to also move them into the site identity/tools block. This doesn't feel at all natural to me, and if this is the direction that is taken, I would strongly advocate having an option to disable it.
This doesn't take into account the identity button. When I first heard this was going to be like this, I thought it was going to be like, when not link is hovered: [SITE.COM] /folder/after/the/identity/button.htm When a link is hovered: [SITE.COM] => satp://super.awesome.site.com/ Can't it be something like this instead?
The identity button would need to be hidden.
Oh. Ignore the above comment. I thought you were referring to the sign-in button for the account manager.
Assignee: nobody → enndeakin
Assignee: enndeakin → adw
Attached patch proof-of-concept patch (obsolete) — — Splinter Review
This proof-of-concept patch simply shows links in the location bar instead of the status bar when you hover over them. No frills. Firefox builds that include this patch are available here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/dwillcoxon@mozilla.com-084989c8fe4d/ Not all builds have finished yet but should be available in several hours or so. These builds will be automatically be deleted in 14 days.
Stephen, could you provide details on the placement of the hovered URL within the location bar? Like: Should the hovered URL always overlap the current URL and if so by how much? Or should the current URL not be overlapped if both URLs fit? Or should the hovered URL simply start at a fixed offset from the start of the location bar? What if the hovered URL is wider than the location bar -- should only it be shown, or should some portions of both be shown and if so how much of each?
Keywords: uiwanted
Oh or Alex, sorry.
(In reply to comment #11) > Created attachment 471030 [details] [diff] [review] > proof-of-concept patch > > This proof-of-concept patch simply shows links in the location bar instead of > the status bar when you hover over them. No frills. Firefox builds that > include this patch are available here: > > http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/dwillcoxon@mozilla.com-084989c8fe4d/ > > Not all builds have finished yet but should be available in several hours or > so. These builds will be automatically be deleted in 14 days. Very nice. Seems to work perfectly!
Stephen and Alex: Also, what should happen when the location bar has focus and the user hovers over a link, or when the user presses Cmd+L while hovering over a link?
CC'ing :l10n and adding [strings] to the whiteboard -- Alex, can you confirm or deny your tentative "Go to:" text requirement from comment 0?
Whiteboard: [strings]
>Alex, can you confirm or deny your tentative "Go to:" text requirement It's cleaner not to have the text, I would be in favor of us landing without it and using the > image, and seeing if the security team wants us to make it more explicit that you are not there yet. >Like: Should the hovered URL always overlap the current URL and if so by how >much? Or should the current URL not be overlapped if both URLs fit? Or should >the hovered URL simply start at a fixed offset from the start of the location >bar? What if the hovered URL is wider than the location bar -- should only it >be shown, or should some portions of both be shown and if so how much of each? I was imagining a fixed percentage of the bar, like the current URL always gets the first 2/3, and the hovered target the last 1/3 >Stephen and Alex: Also, what should happen when the location bar has focus and >the user hovers over a link, or when the user presses Cmd+L while hovering over >a link? I would keep the display of the focused location bar stable, and not display link hovers when it has the focus.
I'm not sure how much of URLs can actually be in RTL script, and if for LTR urls in RTL builds, the ">" image should still be a "<" image. CCing :rtl for that.
(In reply to comment #18) > I'm not sure how much of URLs can actually be in RTL script, and if for LTR > urls in RTL builds, the ">" image should still be a "<" image. CCing :rtl for > that. If you're talking about the ">" sign which appears in the location bar, it really doesn't have anything to do with the direction of the URLs. It's affected by the direction of the location bar itself, which is LTR even in RTL builds. Which means that the image does not need to be flipped for RTL builds. Does this answer your question?
How about showing the go button?
(In reply to comment #19) > (In reply to comment #18) > > Does this answer your question? Yes, thanks.
>If you're talking about the ">" sign which appears in the location bar, it >really doesn't have anything to do with the direction of the URLs. It's >affected by the direction of the location bar itself, which is LTR even in RTL >builds. Which means that the image does not need to be flipped for RTL builds. If we ever make the location bar RTL we should make this change, since the A > B is meant to represent from A to B
(In reply to comment #17) > >Like: Should the hovered URL always overlap the current URL and if so by how > >much? Or should the current URL not be overlapped if both URLs fit? Or should > >the hovered URL simply start at a fixed offset from the start of the location > >bar? What if the hovered URL is wider than the location bar -- should only it > >be shown, or should some portions of both be shown and if so how much of each? > > I was imagining a fixed percentage of the bar, like the current URL always gets > the first 2/3, and the hovered target the last 1/3 Yes, and we also need to ensure that the domain is always shown fully (maybe with some overrides if you have a really, really long hostname like google.com.somethingelse.blah.evilsite.com? Security team should weigh in on this, I guess) We could also truncate the middle part of the URL as long as the entire domain is visible, e.g. mozilla.com/something[…]/nextlevel/here-we-are.html since the end of the URL is more likely to be the second most important part of the URL after the domain itself.
(In reply to comment #20) > How about showing the go button? What about it?
(In reply to comment #22) > >If you're talking about the ">" sign which appears in the location bar, it > >really doesn't have anything to do with the direction of the URLs. It's > >affected by the direction of the location bar itself, which is LTR even in RTL > >builds. Which means that the image does not need to be flipped for RTL builds. > > If we ever make the location bar RTL we should make this change, since the A > > B is meant to represent from A to B Yes, but we're never going to do that (unless there is a fundamental change to how URLs work, and I don't expect it to happen any time soon). :-)
Just in the 5 minutes that I used the tryserver build, I noticed a serious problem. The majority of the time the location bar wasn't showing the current location, but rather some random link that my mouse happened to be over. For example: I click on a link, the new page loads, and there happens to be a link under my cursor. Or I scroll a page, and my cursor up over a link. Either way, I don't notice this. Since I'm now unaware that the location bar is showing a link's URL, it is misleading. This is especially problematic on pages with lots of links or large link target areas. Unless it is very apparent that a link is being shown (or there is some kind of timeout), this change requires the user to be aware of where the cursor is, on a page, in order for the location bar to be meaningful and not misleading. So, for this run, I give it an annoyance factor of 10/10.
I always had something like this in mind. It's not even rough around the edges: it's blatantly underdesigned, but the idea is there. We have the identity button, making sure the site we're in is always identified, and we simply hide the remaining address. We show the hovered URL in black (not gray, as the remaining address is), and with a symbol-like arrow thing to denote that it's the hovered address. Of course, it's crucially important that that arrow thing is very clear, so users KNOW it's hovered URL and not the rest of the current URL. I'm not particularly against putting a "go to" of sorts there, but it'd be better to find a symbolic solution for it. Maybe a stylized link cursor thing, sort of a hand or something... I'm not particularly good at coming up with these things, so I'll leave it to the pros. My suggestion is this, nonetheless.
There also needs to be a way of attracting attention to the location bar. Maybe it could have an animation where the background gently changes it's opacity from 1 to something like 0.75.
This is interesting and might work, but I think the identity button would need to get dimmed a bit at the same time to point out that it's not for the new URL. (dim the old and focus the new) Star and any other location bar icons for the current page would also have to hide. New URL should also get a different background tint of some kind. With this sort of thing we'd need at least a handful of visual indicators. I still like bug 541656 better, but this one is growing on me. Get the cues right (which will be tricky) and it will have a good logical feel to it. The location bar will basically be talking to the user and saying "ok, you want to go here now? click and I'll change it". If this all comes together I and many others will have to re-train our minds to look up top for the target href instead of the bottom, which will be annoying, but if this feature works well enough it'll be worth it. Tiago: By the way, your mockup has the star on the left. That was WONTFIXed in bug 578964.
Removing [strings] from whiteboard given Alex's comment 17.
Status: NEW → ASSIGNED
Whiteboard: [strings]
Attached patch proof-of-concept patch 2 (obsolete) — — Splinter Review
This proof-of-concept patch implements some of the current thinking expressed in this bug: * Hacked up version of Stephen's arrow graphic from comment 1 * Fade in and fade out effect (for kicks! (implementation not perfect!)) * Full host name of hoverlink is always displayed (unless location bar is way small), while path is truncated in the middle if necessary, per Limi's very helpful comment 23 * Unlike Stephen's mockup, this patch keeps the current site ID button, because I think it's a little jarring to have the current URL jump to the left when you hover over a link. It's nice for the hoverlink to just fade in while the current URL remains stationary. (But OTOH I do like the clean, spartan look of the bar without the ID button!) * The icons in the right side of the location bar (star, etc.) fade out as well * Giving the current URL the first 2/3 of the location bar and the hoverlink the remaining 1/3 felt backwards to me when I tried that, so this patch reverses that: the first 1/3 of the bar is the current URL, the final 2/3 the hoverlink (cf. comment 17) * Tested on OS X -- I hope Windows, Linux look OK but maybe not * Doesn't yet handle location bar focus vis-a-vis hoverlinks (cf. comment 17) Alex and other UXers, what do you think? Firefox builds that include this patch will be available here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/dwillcoxon@mozilla.com-b97db6a8518f/ Not all builds have finished yet but should be available in several hours or so. These builds will be automatically be deleted in 14 days.
Attachment #471030 - Attachment is obsolete: true
(In reply to comment #31) > Created attachment 471543 [details] [diff] [review] > proof-of-concept patch 2 > > http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/dwillcoxon@mozilla.com-b97db6a8518f/ Just tested this on Linux. One big problem: cannot interact with the location bar at all when at a page. Can't edit the URL or click the star, etc. > * Hacked up version of Stephen's arrow graphic from comment 1 Arrow graphic needs to be darker so you you can see it better. Not bad though. > * Unlike Stephen's mockup, this patch keeps the current site ID button I agree; I don't think the ID button should change until the page ID changes. > * The icons in the right side of the location bar (star, etc.) fade out as well Works great, even with icons from an addon such as Flagfox.
(In reply to comment #32) > Just tested this on Linux. One big problem: cannot interact with the location > bar at all when at a page. Can't edit the URL or click the star, etc. Rather, I cannot interact with anything with the mouse. If I can get focus by clicking the dropdown arrow I can edit the location using the keyboard.
(In reply to comment #32) > Just tested this on Linux. One big problem: cannot interact with the location > bar at all when at a page. Can't edit the URL or click the star, etc. Oh! Thanks for reporting that. I always use Ctrl+L to get to the location bar (which still works with this patch) and so didn't notice. That'll definitely be fixed.
Also seeing a 1px shift upwards of the origin URL when showing a destination URL. Shifts back down 1px on mouse away from the link.
If possible, hiding the dropdown arrow along with the icons on the right would give a little extra space. While this hover effect is on it's useless anyway. Really long destination URLs become a bit of an issue with the current truncation. There's less space available in the right-side area of the address bar than in the status bar. One possibility would be to marquee the destination URL instead of truncate it. (still truncate the origin, though)
(In reply to comment #31) > * Fade in and fade out effect (for kicks! (implementation not perfect!)) > * The icons in the right side of the location bar (star, etc.) fade out as well My initial impression is that I like this a lot. I was worried about it being distracting but I think the visual treatment and especially the transitions make it very subtle. I need to use it more but right now it feels very nice.
(In reply to comment #36) > If possible, hiding the dropdown arrow along with the icons on the right would > give a little extra space. While this hover effect is on it's useless anyway. I agree. My new patch does this.
Idea: Cut off protocol and domain (and port) in destination URL if they all match the origin URL. For example: Current patch shows: http://www.mozilla.org/about/ > http://www.mozilla.org/about/mission.html Simplify to this: http://www.mozilla.org/about/ > .../about/mission.html This would reduce unneeded redundant showing of the domain and make things much simpler and more clear as to what it will do, i.e. changing path/page on the same domain. This would also help on a small address bar in a small window/screen. Might be some downsides to this, however.
Also, it would be nice if when there's enough space to show both URLs fully, the arrow would move a little bit to avoid truncating one or the other.
I haven't tried the patch yet but have we thought about adding a very slight delay. So when you move the mouse around the screen it won't instantly trigger a bunch of hyperlinks on an instant mouse it, but it also doesn't feel like there is a delay, when you are actually hover on a link intentionally it shows up fast enough that you don't even realize that that is what we are doing.
(In reply to comment #41) > I haven't tried the patch yet but have we thought about adding a very slight > delay. So when you move the mouse around the screen it won't instantly trigger > a bunch of hyperlinks on an instant mouse it, but it also doesn't feel like > there is a delay, when you are actually hover on a link intentionally it shows > up fast enough that you don't even realize that that is what we are doing. Yes, these are my thoughts too. With the latest posted patch there's a delay of 50ms when both starting hover and ending hover. I want to be careful not to delay too much on start, because it's these small kinds of things that contribute to the perception that Firefox is slow. Especially if you hover a link with the sole purpose of seeing its URL.
The new build is a definite improvement. At least now it is visually apparent that a target URL is being displayed. However, at least of the sites I frequent, it still shows a target URL more often than the current URL. I definitely think there should be a timeout (maybe 5 seconds / configurable) before reverting back to the current URL. Also, moving the cursor should reset the timer or reshow the target URL. That way you can see the URL again by twitching the cursor instead of doing a mouseout+mouseover. Also, I like the minor delay on mouseover. But I don't think it needs a delay on mouseout.
Drew, awesome work with the transitions! :) (In reply to comment #41) > I haven't tried the patch yet but have we thought about adding a very slight > delay. So when you move the mouse around the screen it won't instantly trigger > a bunch of hyperlinks on an instant mouse it, but it also doesn't feel like > there is a delay, when you are actually hover on a link intentionally it shows > up fast enough that you don't even realize that that is what we are doing. Quantitatively, this means the delay should probably remain < 100 ms. The current delay of 50ms seems to work well. At least on my machine (latest MacBook Pro), the transition _duration_ feels slow and seems to slow. 200ms might be too long. I realize that this is difficult and perhaps impossible with pure CSS transitions, but when mousing over a link before the fade-out transition ends, we should immediately (or very quickly) show the link URL at full opacity. FWIW, here's Chromium's design doc for their status bubble: http://dev.chromium.org/user-experience/status-bubble It describes the various transitions and timeouts that they use when mousing over/out of or between links. In case you didn't catch this yet, I also run into the problem of not being about to interact with the location bar via the mouse. Again, awesome work, Dave! :) (In reply to comment #43) > The new build is a definite improvement. At least now it is visually apparent > that a target URL is being displayed. Please read the bug description and check the mockups before commenting. Your previous comment complained about the current URL being covered by the link URL, when the patch was clearly a work-in-progress, and both the mockups and description explained otherwise.
(In reply to comment #40) > Also, it would be nice if when there's enough space to show both URLs fully, > the arrow would move a little bit to avoid truncating one or the other. Yeah, one thing I don't like is that when the window is small, the current URL is sometimes needlessly truncated, and when the window is big, sometimes there's lots of oddly distributed whitespace. OTOH, there is value in keeping the position of the hoverlink constant, since it creates spatial memory. (In reply to comment #43) > I definitely think there should be a timeout (maybe 5 seconds / configurable) > before reverting back to the current URL. That's an idea. UXers? (Rewording: After hovering for N seconds, go back to showing only the current URL.) > Also, I like the minor delay on mouseover. But I don't think it needs a delay > on mouseout. The idea is that if you quickly mouse from link to link, you don't want the location bar flashing back to the current URL between each link. I also think the delay here is much less critical that the one on mouseover. (In reply to comment #44) Thanks Frank, this is helpful. > I realize that this is difficult and perhaps impossible with pure CSS > transitions, but when mousing over a link before the fade-out transition ends, > we should immediately (or very quickly) show the link URL at full opacity. Yeah, that'd be nice, I'll see what I can do. > FWIW, here's Chromium's design doc for their status bubble: Whoa, they have a design doc for their status bubble... that's Big Leagues.
Attached patch proof-of-concept patch 3 (obsolete) — — Splinter Review
This proof-of-concept patch makes the following changes from the previous: * Fixed bug that prevented mouse interaction with location bar * Hide dropdown arrow (at the far right of the bar) too on hover * If the bar is focused or has been edited, don't show hoverlink * Slightly decreased transition durations per Frank's comment 44 * Slight opacity gradient at end of current URL when it's truncated per comment 1 mockup (barely noticeable, help me Stephen) * Reminder: this might look like crap on Windows, Linux UX fellows, I think this is at a good enough state to test the ideas you've provided so far. Firefox builds that include this patch will be available here (link not currently live): http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/dwillcoxon@mozilla.com-23abf2350b22/ All builds should be available in several hours or so. These builds will be automatically be deleted in 14 days.
Attachment #471543 - Attachment is obsolete: true
(In reply to comment #45) > (In reply to comment #40) > > Also, it would be nice if when there's enough space to show both URLs fully, > > the arrow would move a little bit to avoid truncating one or the other. > > Yeah, one thing I don't like is that when the window is small, the current URL > is sometimes needlessly truncated, and when the window is big, sometimes > there's lots of oddly distributed whitespace. OTOH, there is value in keeping > the position of the hoverlink constant, since it creates spatial memory. That's why I said move "a little bit". It'll be a balancing act between trying to show as much as possible without moving things too much. > (In reply to comment #43) > > I definitely think there should be a timeout (maybe 5 seconds / configurable) > > before reverting back to the current URL. > > Rewording: After hovering for N seconds, go back to showing only the current URL. I like this idea too. Idle state should be normal. > (In reply to comment #44) > > FWIW, here's Chromium's design doc for their status bubble > > Whoa, they have a design doc for their status bubble... that's Big Leagues. FWIW, it's a very short doc. Nice and concise, though. ;)
Attached image broken dropdown arrow (Linux) (obsolete) —
(In reply to comment #46) > Created attachment 471676 [details] [diff] [review] > proof-of-concept patch 3 > > http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/dwillcoxon@mozilla.com-23abf2350b22/ Tested new build on Linux. (Linux try server builds seem to generate first) > * Fixed bug that prevented mouse interaction with location bar Works now. > * Hide dropdown arrow (at the far right of the bar) too on hover Effect works but the dropdown arrow image breaks, at least on Linux. (see attached) > * Reminder: this might look like crap on Windows, Linux Everything looks like crap on Linux as they've yet to update the damn theme. :(
Even with lots of space available it truncates more than is needed. The arrow location needs to be smarter to avoid issues. (see attached example)
Attachment #466903 - Attachment description: Hyperlink Hover in the Location Bar → Hyperlink Hover in the Location Bar Mockup
In last try server build it works fine for me.
Shouldn't the current address be as left aligned as possible and the right address be as right aligned as possible, only truncating the current address if space runs out. Having empty space on the right doesn't quite look right.
Issue: bug 544816 adding the new combined multi-state load button ( attachment 471833 [details] ) Option #1: Hide it on hover with all the rest of the stuff on the right Option #2: Set its state to the green go button to indicate a click will "go" Option #3: Add a new button state for the hover effect that's better than #2
Option #0: Ignore it and just leave the plain refresh button state
Attached patch proof-of-concept patch 4 (obsolete) — — Splinter Review
This proof-of-concept patch... * right-aligns the hoverlink. * truncates the hoverlink's path portion at the start rather than the middle, so you end up with "http://example.com...some-long-path" instead of "http://example.com/start-...-path". * fades out the end of the current URL when necessary. * has not been tested on Windows or Linux. Of all the patches, this is closest to shippable quality I think. Asking for (first) ui-review to get that ball rolling. Firefox builds that include this patch will be available here (link not yet live): http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/dwillcoxon@mozilla.com-385c75a4970c/ All builds should be available in several hours or so. These builds will be automatically be deleted in 14 days.
Attachment #471676 - Attachment is obsolete: true
Attachment #471708 - Attachment is obsolete: true
Attachment #472152 - Flags: ui-review?(faaborg)
Attachment #471719 - Attachment is obsolete: true
Attachment #471720 - Attachment is obsolete: true
Comment on attachment 471708 [details] broken dropdown arrow (Linux) This problem still occurs in the new build on Linux with KDE4.4. Is anyone else seeing this? If so, what OS and DE?
Attachment #471708 - Attachment description: broken dropdown arrow from newest build (Linux) → broken dropdown arrow (Linux)
Attachment #471708 - Attachment is obsolete: false
OK, I shouldn't have marked that screenshot as obsolete. As I've said, I haven't tested on Linux or Windows, and minor problems like that will be fixed in a future non-proof-of-concept-for-reals-y'all patch.
(In reply to comment #55) > Created attachment 472152 [details] [diff] [review] > proof-of-concept patch 4 > > http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/dwillcoxon@mozilla.com-385c75a4970c/ > * right-aligns the hoverlink. > * truncates the hoverlink's path portion at the start rather than the > middle, so you end up with "http://example.com...some-long-path" > instead of "http://example.com/start-...-path". > * fades out the end of the current URL when necessary. Much better and fewer issues now. I think it may be good to try just having the arrow at the end of the origin URL regardless of length (until truncation). This is getting into the tweaking issues now. The idea itself is working but needs to have some UI polishing. As to two issues I mentioned above: comment 53: You went with option #1; the new go/reload/stop button is also hidden on hover. I think this works nicely with the right-alignment. comment 35: The origin URL 1px up/down jitter bug is fixed now. Thanks. (In reply to comment #57) > OK, I shouldn't have marked that screenshot as obsolete. As I've said, I > haven't tested on Linux or Windows, and minor problems like that will be fixed > in a future non-proof-of-concept-for-reals-y'all patch. Agreed; theming will probably need followup bugs. I'll quote the attachment number in a new one for that issue if needed. Other two screenshots are obsolete now though.
In the latest try server build when hovering on a link I can't see the semi transparent arrow to the right of the URL (as shown in the screenshot) and the white star for bookmarking the site and the arrow that displays the list of visited sites disappears too (when hovering on a link).
Just noticed in the latest builds that the current URL is visible through the path portion of the hoverlink. Careless error with an easy fix. Use your imagination in the meantime. (In reply to comment #59) > In the latest try server build when hovering on a link I can't see the semi > transparent arrow to the right of the URL (as shown in the screenshot) and the > white star for bookmarking the site and the arrow that displays the list of > visited sites disappears too (when hovering on a link). Don't worry about the first part right now, the second part is by design.
(In reply to comment #60) > Just noticed in the latest builds that the current URL is visible through the > path portion of the hoverlink. Careless error with an easy fix. Use your > imagination in the meantime. > > (In reply to comment #59) > > In the latest try server build when hovering on a link I can't see the semi > > transparent arrow to the right of the URL (as shown in the screenshot) and the > > white star for bookmarking the site and the arrow that displays the list of > > visited sites disappears too (when hovering on a link). > > Don't worry about the first part right now, the second part is by design. By design meaning it's the expected behavior?
(In reply to comment #61) > By design meaning it's the expected behavior? Indeed. ;-)
Ah, ok then! ;-)
Drew, great work again! :) (In reply to comment #55) > Created attachment 472152 [details] [diff] [review] > proof-of-concept patch 4 > > This proof-of-concept patch... > > * right-aligns the hoverlink. Haven't tested this yet, but my intuition is that right-aligning the hoverlink causes more jarring text movement. It makes more sense to me to keep the domain name from moving around. Feedback from UX team? (In reply to comment #59) > ... and the arrow that displays the list of > visited sites disappears too (when hovering on a link). IIRC, from my discussions with the UX team (when I was an intern), we actually want to get rid of the dropmarker altogether. (If you wish to discuss that, please use bug 593624.)
My current aesthetics opinions: 1) Have arrow directly to the right of the (left aligned) origin URL always, regardless of where this positions it relative to the rest of the location bar. 2) Gradient fade out for last ~100px before arrow 3) Within the right-hand-side box for the destination URL, consider centering the destination URL. This would distribute space more evenly. If this doesn't work out, regular left alignment to the right of the arrow may be better. The full right alignment not quite right, I think.
> (In reply to comment #59) > > ... and the arrow that displays the list of > > visited sites disappears too (when hovering on a link). > > IIRC, from my discussions with the UX team (when I was an intern), we actually > want to get rid of the dropmarker altogether. (If you wish to discuss that, > please use bug 593624.) Not really. I just didn't know it was the intended behavior because it's not what the 2 first screenshots show. In fact, both of them show the star, the dropdown and the refresh icon, which BTW also disappears when hovering on a link.
(In reply to comment #64) > (In reply to comment #59) > > ... and the arrow that displays the list of > > visited sites disappears too (when hovering on a link). > > IIRC, from my discussions with the UX team (when I was an intern), we actually > want to get rid of the dropmarker altogether. (If you wish to discuss that, > please use bug 593624.) Sorry, I meant the above as reply to comment #64 Not really. I just didn't know it was the intended behavior because it's not what the 2 first screenshots show. In fact, both of them show the star, the dropdown and the refresh icon, which BTW also disappears when hovering on a link.
Note that setOverLink gets decoded URLs. Converting them to nsIURI breaks this (re-encodes the URLs).
Comment on attachment 472152 [details] [diff] [review] proof-of-concept patch 4 I won't be able to do the review until about 2am pacific (just reading bugmail on my phone at the moment). If Limi or shorlander can get it to before then feel free :)
Attached image issues with proof-of-concept 4 patch (obsolete) —
Noticed a couple of things on windows -the hovered url has a kind of white rectangle around it. -when the hovered url's too long to fit the window size, it partially covers the url you're on -it's truncated weirdly "bugzilla.org...g.cgi?idxxxxxx"
(In reply to comment #70) > -it's truncated weirdly > "bugzilla.org...g.cgi?idxxxxxx" Thanks for testing it, but "weirdly" is not especially helpful. Any suggestions on how it should truncate? My suggestion: We should not truncate the first "/" of the path to make it clear that the part being truncated is in fact the path not higher-level domains. For example: "bugzilla.org...g.cgi?idxxxxxx" could mean: * "bugzilla.org.evil.com/show_bug.cgi?idxxxxxx" or * "bugzilla.org/show_bug.cgi?idxxxxxx" whereas "bugzilla.org/...g.cgi?idxxxxxx" unambiguously means that the domain is bugzilla.org
> (In reply to comment #70) mmm you do make a good point. I guess the only thing that seems weird is the ...g.cgi. Why isn't the .g. part truncated? Also, The hovered url isn't vertically centered. Alignment's off by about a pixel or two.
(In reply to comment #71) > Any suggestions on how it should truncate? comment 39 -> drop the scheme, domain, and port if they are identical to the origin's comment 36 -> consider sometimes doing a marquee instead of just truncating Possible route for long destination URLs: 1) drop domain if it's duplicate info: http://example.com/here > .../there 2) if the destination URL still doesn't fit, then truncate at the end: http://example.com/here > .../there/at/some/long/path/that/doesnotfit... 3) after a second or two of hovering, marquee the full destination URL. The shown part goes to the left revealing the end part that was truncated, cycling around to show the beginning and repeat. This would truncate smartly but still allow for the ability to see everything if needed.
Oh, and to state what should be obvious, I am *not* suggesting the use of the actual <marquee> tag, just a marquee effect. :)
(In reply to comment #73) or 2b) smart truncate out the middle, then revert to end truncation when the marquee starts. (just brainstorming here) Thus we start as: http://example.com/here > .../there/at/some/long/.../reallylong/page.html then after 1 or 2 seconds the destination URL changes to the following, which doesn't fit anymore: http://example.com/here > .../there/at/some/long/path/that/doesnotfit/because/the/path/is/reallylong/page.html but is truncated to fit (without the "..."): http://example.com/here > .../there/at/some/long/path/that/doesnotfit/beca which then slides to the left to show more of the right portion and cycles around to the beginning and repeats. Eventually we get this: http://example.com/here > doesnotfit/because/the/path/is/reallylong/page.h then: http://example.com/here > path/is/reallylong/page.html .../there/at/some/ then continued cycling at least once more so the user can see the full URL again (I hope that was somewhat clear) The later part not fitting would marquee around showing less on the left and more on the right, continually cycling until the full destination URL is shown at least twice, then eventually reverting to normal origin only state after 5-10 seconds as proposed above. Bit complex, but it shows some minimal info simply but also gives a route to show it all.
Comment on attachment 472152 [details] [diff] [review] proof-of-concept patch 4 Testing on windows 7, overall definitely good enough to land for us to get more of a feel for it. The timing felt good, and I really liked the fade animation. Two nits: I didn't see the > graphic that Stephen created, and I was getting a fully opaque white background on the domain name (that didn't mesh with the color of the unfocused location bar on the windows theme).
Attachment #472152 - Flags: ui-review?(faaborg) → ui-review+
Forgot to add, the drop down arrow in the location bar also wasn't functional with the tryserver builds.
Attached patch work-in-progress patch (obsolete) — — Splinter Review
This work-in-progress patch takes the UX of the previous proof-of-concept patch and starts to make it production quality. Additionally, it makes these UX changes: * Leading slash of path is not truncated (comment 71) * Hoverlink is shown immediately (without fade-in) if it's currently being faded in or out (comment 44) * Exaggerated transition durations for testing purposes I had a lot of trouble getting the fade in and out of the current URL to look good. If you transition the opacities of two labels that are directly on top of each other, there is very noticeable jiggle/flicker as the antialiasing from each merges and interacts. (You can see this in the second and third proofs-of-concept patches.) I had better luck transitioning their text colors instead, and that's what this patch does. I spent a lot of time trying different approaches and different transition timing functions. I also tried dividing the current URL into two HTML canvases, one that's overlapped by the hover link and which fades in and out, and one that's not and remains static. That kind of worked but it's a Rube Goldberg machine. I can't simply obscure the current URL with a background on the hoverlink (like proof of concept 4 does) because when a lightweight theme is enabled on Windows, it shows through the URL bar. The approach I settled on isn't perfect: you can still see a slight "pulse" in the current URL when you mouseover a link if you use a software magnifying glass. My (bad) eyes don't notice it at normal zoom. If this approach isn't production quality, I don't know what to do. Patch only tested on OS X. Next: Windows and Linux styling and testing.
Attachment #472152 - Attachment is obsolete: true
Sorry to spam this bug, but is there any way we can resolve TinyURL's as proper locations? These have become rather ubiquitous and should probably be treated as a possibly serious security threat. Should I make a new bug and link to here?
(In reply to comment #79) > Sorry to spam this bug, but is there any way we can resolve TinyURL's as proper > locations? These have become rather ubiquitous and should probably be treated > as a possibly serious security threat. Should I make a new bug and link to > here? There are extensions that will do this for you, it should not be a part of the stock product: https://addons.mozilla.org/en-US/firefox/addon/162021/ https://addons.mozilla.org/en-US/firefox/addon/58517/ https://addons.mozilla.org/en-US/firefox/addon/8636/
>There are extensions that will do this for you, it should not be a part of the >stock product: at least not yet, but I'm leaning in the direction that these are universally annoying enough to potentially some day warrant fixing in the main product.
(In reply to comment #81) > >There are extensions that will do this for you, it should not be a part of the > >stock product: > > at least not yet, but I'm leaning in the direction that these are universally > annoying enough to potentially some day warrant fixing in the main product. Please do consider it. Redirected links in general are something potentially very dangerous, and it would be nice to see this nipped in the bud soon instead of waiting for this to be exploited on an even more massive scale than it currently is. A question about the style of the link being displayed in the urlbar: Shouldn't the target-link be styled similar to a default text link... blue with an underline to make it clear to the user that what they are seeing is a link and not some weird perversion of the main url? Lastly, on truncating the links: When dealing with a link that includes a long list of flags... it should be safe to cut off the flags. Basically, everything after the first "&" can usually be cut off without loosing any important information about the link.
Also, stylistically speaking, the > arrow reminds me of 3.X style buttons... shouldn't you be using either the Forward or Go button graphic for this?
(In reply to comment #81) > >There are extensions that will do this for you, it should not be a part of the > >stock product: > > at least not yet, but I'm leaning in the direction that these are universally > annoying enough to potentially some day warrant fixing in the main product. The same can be said about adverts surely?
(In reply to comment #82) > A question about the style of the link being displayed in the urlbar: > Shouldn't the target-link be styled similar to a default text link... blue with > an underline to make it clear to the user that what they are seeing is a link > and not some weird perversion of the main url? No underlined blue URL up top please. This essentially tells the user to click up there, which is the opposite of the point. A blue arrow might be nice though.
Attached patch reviewable patch 1 (obsolete) — — Splinter Review
I think this is good enough to start the review process. I haven't run tests yet, and there should probably be a new test to cover this... CSS for Windows, OS X, and Linux is complete, and in my visual testing on Windows Vista, OS X, and Ubuntu, everything looks OK. Haven't visually tested on Windows XP yet. Firefox builds that include this patch will be available here in several hours or so (link not yet live): http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/dwillcoxon@mozilla.com-62621772d7e4/ These builds will be automatically deleted in 14 days.
Attachment #472757 - Attachment is obsolete: true
Attachment #473439 - Flags: review?(dao)
In the last build above it looks good! At least in Windows 7 it does.
Comment on attachment 471708 [details] broken dropdown arrow (Linux) The bug in this screenshot is now fixed in the current patch version.
Attachment #471708 - Attachment is obsolete: true
Comment on attachment 473439 [details] [diff] [review] reviewable patch 1 Definitely looking good enough for review starting now. Still needs some styling tweaking though, also see my comments about truncation issues above. I really think the arrow needs to be a little darker and blue or green.
Attachment #472219 - Attachment description: issues → issues with proof-of-concept 4 patch
Attachment #472219 - Attachment is obsolete: true
Whiteboard: [has patch][needs review dao]
(In reply to comment #87) > In the last build above it looks good! At least in Windows 7 it does. Thanks. However, I just tried on Windows 7, and when I moused over a link, the current URL and hoverlink are shifted down one or two pixels too many. That's not supposed to happen, and doesn't happen on Vista. Do you see that too? (Not sure if it's related, but it looks like the Windows 7 version of browser.css ends up being different from Vista's -- presumably because of some build step.) Another problem: opening the toolbar customization palette breaks everything.
Keywords: uiwanted
Attached patch reviewable patch 2 (obsolete) — — Splinter Review
This fixes the breakage after opening the toolbar customization palette. I was caching nodes to avoid traversing the DOM on every link mouseover, and opening the palette apparently and not surprisingly breaks that. So this patch doesn't cache anymore. I assume the Windows 7 styling issue in comment 90 has a simple fix and will focus on tests now.
Attachment #473439 - Attachment is obsolete: true
Attachment #473722 - Flags: review?(dao)
Attachment #473439 - Flags: review?(dao)
(In reply to comment #90) > (Not sure if it's related, but it looks like the Windows 7 version of > browser.css ends up being different from Vista's -- presumably because of some > build step.) Nope, it's the very same browser.css. XP has a different one.
Attached patch reviewable patch 3 (obsolete) — — Splinter Review
This patch adds a simple browser chrome smoke test that makes sure a link appears in the location bar when moused over and does not appear when moused out. All existing browser chrome tests pass (on my machine). Still investigating the Windows 7 style issue from comment 90.
Attachment #473722 - Attachment is obsolete: true
Attachment #474190 - Flags: review?(dao)
Attachment #473722 - Flags: review?(dao)
Looking good — don't let this affect anything as far as review goes (as it's just a polish issue we can handle later), but we shouldn't be moving the separator around. It should start from the same point every time (e.g. middle of the URL bar), and not be right-aligned. By moving it around based on the length of the URL, we're making it harder to quickly take a look at it.
OK, to clarify (and after speaking to faaborg about it: * 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. * In pathological cases where the domain name is very long (is the max still 63 characters?), we should strive to keep all of the domain displayed. * For phishing reasons, we should also truncate subdomains when we run out of space, like this: http://www.friendly.reader.google.com.somephishingdomain.com/someverylongelementgoeshere becomes …somephishingdomain.com/…goeshere And again, this is polish stuff, and we shouldn't stop trying to land the current code for this without the above improvements — it should be able to land later, as far as I can see.
I'm dumb: the Windows 7 styling problem I saw in comment 90 was due to some userChrome.css modifications I'd made while diagnosing another problem.
(In reply to comment #94) > Looking good — don't let this affect anything as far as review goes (as it's > just a polish issue we can handle later), but we shouldn't be moving the > separator around. It should start from the same point every time (e.g. middle > of the URL bar), and not be right-aligned. > > By moving it around based on the length of the URL, we're making it harder to > quickly take a look at it. 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).
Tested on Windows XP. When you mouseover a link, the origin and hoverlink labels are off by one pixel, but other than that looks OK. I'll batch that fix with others prompted by review.
Comment on attachment 474190 [details] [diff] [review] reviewable patch 3 See comment 68, you can extract the host with a regular expression. >+ <xul:scrollbox flex="1" anonid="origin-box"> >+ <xul:label anonid="origin-label" flex="1" crop="end"/> >+ </xul:scrollbox> What's the point of this scrollbox? Your binding content depends on transitions in the theme, which isn't good. browser/base/content/browser.css should define this transition or at least a stub transition. The transitionend event bubbles and will be dispatched for each transitioning property. You need to check the event target as well as the property. Get rid of all the [anonid=...] selectors, use classes instead. >-#urlbar > .autocomplete-textbox-container { >+#urlbar .autocomplete-textbox-container { > -moz-appearance: none; > /* keep the URL bar content LTR */ > direction: ltr; > } You should probably add new classes for such cases, so that you can use e.g. .urlbar-textbox-container instead of making this selector less efficient. >-#wrapper-urlbar-container #urlbar > .autocomplete-history-dropmarker { >+#wrapper-urlbar-container #urlbar .autocomplete-history-dropmarker { > display: none; > } Probably better to just get rid of this...
Attachment #474190 - Flags: review?(dao) → review-
Attached patch reviewable patch 4 (obsolete) — — Splinter Review
(In reply to comment #99) All comments addressed, with these notes: This patch additionally 1) updates some #urlbar child selectors that the previous patch missed; 2) sets the over-link path label to crop at the end, not the start, when there is no host; 3) makes the Windows XP style fix (comment 98). > See comment 68, you can extract the host with a regular expression. Preemptive explanation: my URL regexp is liberal with the scheme, but it follows RFC 1738. I don't use the regexp literal syntax so as to avoid having to escape the slashes. > What's the point of this scrollbox? No point, removed. It was leftover from experimenting with the origin URL crop fade of the mockup (attachment 466903 [details]). I don't know of a nice way to implement that, so I'm leaving it for follow-up polish and going with an ellipsis for now. If you have ideas, possibly for landing with this bug, that would be great. > >-#urlbar > .autocomplete-textbox-container { > >+#urlbar .autocomplete-textbox-container { > > -moz-appearance: none; > > /* keep the URL bar content LTR */ > > direction: ltr; > > } > > You should probably add new classes for such cases, so that you can use e.g. > .urlbar-textbox-container instead of making this selector less efficient. This patch uses only child selectors instead, which (unless I'm wrong, you'd know better) are at least as efficient as your suggestion. The reason is that I can't avoid some kind of child or descendant selectors since I'm setting the "overlinkstate" attribute on #urlbar, which seems better than the alternative of setting a similar attribute on many of its descendants.
Attachment #474190 - Attachment is obsolete: true
Attachment #474417 - Flags: review?(dao)
Attached patch reviewable patch 4.1 (obsolete) — — Splinter Review
Typos in winstripe/browser/browser.css.
Attachment #474417 - Attachment is obsolete: true
Attachment #474430 - Flags: review?(dao)
Attachment #474417 - Flags: review?(dao)
Attached patch reviewable patch 4.2 (obsolete) — — Splinter Review
Noticed a bug in determining whether to show over-link: type in the URL bar, don't hit Enter, click a link in the page. When you mouseover a link in the new page, the over-link doesn't appear. It won't appear until you either hit Esc in the URL bar or navigate to a new page using the URL bar. I could add an event listener on the browser to reset _textModified on page load. But I think a better solution is just to show the over-link when the URL bar is not focused, regardless of the text it contains. Not only is that less bookkeeping and less fragile, but it makes UX sense. If you type in the URL bar, blur the URL bar, and then mouseover a link, you probably want to see the link. You're at least no longer focusing your attention on the URL bar. (Note that if the URL bar is focused, the over-link is hidden no matter what text it contains.)
Attachment #474430 - Attachment is obsolete: true
Attachment #474440 - Flags: review?(dao)
Attachment #474430 - Flags: review?(dao)
Single class selectors with inherited attributes are likely more efficient than the child selectors. Obviously it would also simplify the CSS. Last but not least, it's less fragile as extensions can extend the binding and add another container layer or something, which would break with the child selectors.
OK. Do you also want to replace the "overlinkstate" attribute on #urlbar, which has two possible values and requires 11 rules that use a chain of child selectors (browser/base/content/browser.css), with two new classes on each of the appropriate descendants of #urlbar?
Or maybe that's what you meant by "with inherited attributes", I'm not sure. Anonymous descendants inherit #urlbar's overlinkstate attribute as their class?
(In reply to comment #105) > Anonymous descendants inherit #urlbar's overlinkstate attribute as their class? As an attribute, e.g. xbl:inherits="overlinkstate".
Attached patch reviewable patch 5 (obsolete) — — Splinter Review
There are a couple of rules with #urlbar pseudo-class selectors that I couldn't convert to simple class selectors, one in browser/base/content/browser.css and another in winstripe/browser/browser.css. (In reply to comment #99) > >-#wrapper-urlbar-container #urlbar > .autocomplete-history-dropmarker { > >+#wrapper-urlbar-container #urlbar .autocomplete-history-dropmarker { > > display: none; > > } > > Probably better to just get rid of this... Did you want to remove all #wrapper-urlbar-container rules, all of the ones I'm touching, or only this one in gnomestripe? I had to modify one in winstripe too, and I've not removed it.
Attachment #474440 - Attachment is obsolete: true
Attachment #474572 - Flags: review?(dao)
Attachment #474440 - Flags: review?(dao)
Attached patch reviewable patch 5.1 (obsolete) — — Splinter Review
Test was assuming that the location bar's text color is black, failing where that's not the case, which is at least on gnomestripe. Fixed.
Attachment #474572 - Attachment is obsolete: true
Attachment #474762 - Flags: review?(dao)
Attachment #474572 - Flags: review?(dao)
Comment on attachment 474762 [details] [diff] [review] reviewable patch 5.1 >--- a/browser/base/content/browser.css >+++ b/browser/base/content/browser.css > /* Some child nodes want to be ordered based on the locale's direction, while > everything else should be ltr. */ >-#urlbar:-moz-locale-dir(rtl) > .autocomplete-textbox-container > .textbox-input-box { >+#urlbar:-moz-locale-dir(rtl) > stack > .autocomplete-textbox-container > .textbox-input-box { > direction: rtl; > } .urlbar-textbox-input-box:-moz-locale-dir(rtl) > #urlbar html|*.autocomplete-textbox { > direction: ltr; > } html|*.urlbar-textbox >--- a/browser/themes/winstripe/browser/browser.css >+++ b/browser/themes/winstripe/browser/browser.css >-#urlbar:-moz-lwtheme > .autocomplete-textbox-container > .textbox-input-box > html|*.textbox-input:-moz-placeholder, >+#urlbar:-moz-lwtheme > stack > .autocomplete-textbox-container > .textbox-input-box > html|*.textbox-input:-moz-placeholder, > .searchbar-textbox:-moz-lwtheme > .autocomplete-textbox-container > .textbox-input-box > html|*.textbox-input:-moz-placeholder { > color: #777; > } html|*.urlbar-textbox:-moz-lwtheme However, the class should probably be called urlbar-input really. >+.urlbar-origin-label { >+%ifdef WINSTRIPE_AERO >+ padding: 4px 0 0 4px; >+%else >+ padding: 5px 0 0 4px; >+%endif >+.urlbar-over-link-box { >+ position: relative; >+ right: 0; >+ color: GrayText; >+ background: url(chrome://browser/skin/urlbar-over-link-arrow.png) no-repeat left center; >+%ifdef WINSTRIPE_AERO >+ padding: 4px 5px 0 18px; >+%else >+ padding: 5px 5px 0 18px; >+%endif This looks fragile. Have you tested this without DirectWrite on Win7? Also with different font sizes?
> > >-#wrapper-urlbar-container #urlbar > .autocomplete-history-dropmarker { > > >+#wrapper-urlbar-container #urlbar .autocomplete-history-dropmarker { > > > display: none; > > > } > > > > Probably better to just get rid of this... > > Did you want to remove all #wrapper-urlbar-container rules, all of the ones I'm > touching, or only this one in gnomestripe? I had to modify one in winstripe > too, and I've not removed it. This wasn't gnomestripe-specifc, I really meant all themes. I didn't mean all rules possibly involving #wrapper-urlbar-container, though, just that one with the dropmarker.
Whiteboard: [has patch][needs review dao] → [has patch]
Attached patch reviewable patch 5.2 (obsolete) — — Splinter Review
Addresses comments. (In reply to comment #109) > >+.urlbar-over-link-box { > >+ position: relative; > >+ right: 0; > >+ color: GrayText; > >+ background: url(chrome://browser/skin/urlbar-over-link-arrow.png) no-repeat left center; > >+%ifdef WINSTRIPE_AERO > >+ padding: 4px 5px 0 18px; > >+%else > >+ padding: 5px 5px 0 18px; > >+%endif > > This looks fragile. Have you tested this without DirectWrite on Win7? Also with > different font sizes? No, will do. Any less fragile suggestions? (In reply to comment #110) > This wasn't gnomestripe-specifc, I really meant all themes. I didn't mean all > rules possibly involving #wrapper-urlbar-container, though, just that one with > the dropmarker. OK, removed #wrapper-urlbar-container-plus-dropmarker rules in all themes.
Attachment #474762 - Attachment is obsolete: true
Attachment #474781 - Flags: review?(dao)
Attachment #474762 - Flags: review?(dao)
(In reply to comment #109) > >+.urlbar-over-link-box { > >+ position: relative; > >+ right: 0; > >+ color: GrayText; > >+ background: url(chrome://browser/skin/urlbar-over-link-arrow.png) no-repeat left center; > >+%ifdef WINSTRIPE_AERO > >+ padding: 4px 5px 0 18px; > >+%else > >+ padding: 5px 5px 0 18px; > >+%endif > > This looks fragile. Have you tested this without DirectWrite on Win7? Also with > different font sizes? I presume this means gfx.font_rendering.directwrite.enabled set to false? It's been false on my stock testing profile. When I flip it on, I don't see any difference. Different (Windows) system font sizes are a problem though, the alignment's off. I've fixed this by setting align="center" on .urlbar-over-link-layer and .urlbar-over-link-box. The problem now is getting the arrow image to grow to fill the location bar. Setting a min-height per theme on .urlbar-over-link-box seems to work OK, but since I'm not stretching the image, there can be blank space above and below the image when the bar is taller than it. I'm not worried about that, not right now anyway. I'll test my fixes on gnomestripe and then attach a new patch.
Attached patch reviewable patch 6 (obsolete) — — Splinter Review
Makes changes mentioned in comment 112. Also, the arrow graphic on gnomestripe wasn't filling the entire height of the bar, so I've fixed that by setting a negative margin on .urlbar-over-link-layer like #urlbar > toolbarbutton does so that stop-go-reload fills the entire height.
Attachment #474781 - Attachment is obsolete: true
Attachment #474895 - Flags: review?(dao)
Attachment #474781 - Flags: review?(dao)
Comment on attachment 474895 [details] [diff] [review] reviewable patch 6 RTL layout seems to be busted. Not tested yet? Probably needs testing on all platforms as well. I'm on Linux. >- setOverLink: function (link, b) { >- // Encode bidirectional formatting characters. >- // (RFC 3987 sections 3.2 and 4.1 paragraph 6) >- this.overLink = link.replace(/[\u200e\u200f\u202a\u202b\u202c\u202d\u202e]/g, >- encodeURIComponent); >- this.updateStatusField(); >+ setOverLink: function (link) { >+ gURLBar.setOverLink(link); > }, Keep the .replace here, any extension overriding setOverLink will want to copy it. >+ this._anonElt("over-link-box").addEventListener("transitionend", this, >+ false); It looks like all the this._anonElt(...) nodes should have a field instead. E.g. <field name="_overLinkBox" readonly="true"> document.getAnonymousElementByAttribute(this, "anonid", "over-link-box"); </field> Note that this should actually be the anonid attribute, not class, as elements can have multiple classes. >diff --git a/browser/themes/pinstripe/browser/browser.css b/browser/themes/pinstripe/browser/browser.css >--- a/browser/themes/pinstripe/browser/browser.css >+++ b/browser/themes/pinstripe/browser/browser.css >+#wrapper-urlbar-container > * > * > * > * > #identity-icon-labels { > display: none; > } drop this too
Attachment #474895 - Flags: review?(dao) → review-
(In reply to comment #114) > RTL layout seems to be busted. Not tested yet? Probably needs testing on all > platforms as well. I'm on Linux. By "busted" you mean the origin label's alignment is off by a couple of pixels, right? That's the only problem I see on OS X. Is it appropriate to use :-moz-locale-dir(rtl) rules to fine tune the alignment? Are there any other problems with this patch?
OK, I see that on Windows the favicon is at the right of the bar, and on mouseover the over-link and origin URL are switched. Think I know how to fix. Still, are there any other problems with this patch?
Should be pretty close otherwise. The URL didn't display correctly with RTL on Linux. I got something like show_bug.cgi?id=587908/https://bugzilla.mozilla.org, don't remember exactly. Alignment problems might be due to your use of (margin/padding)-(left/right) instead of -moz-(margin/padding)-(start/end).
Comment on attachment 474895 [details] [diff] [review] reviewable patch 6 >+ <xul:hbox anonid="textbox-input-box" >+ class="textbox-input-box urlbar-textbox-input-box" >+ flex="1" xbl:inherits="tooltiptext=inputtooltiptext"> >+ <children/> urlbar-input-box may be better than urlbar-textbox-input-box...
Attached patch reviewable patch 7 (obsolete) — — Splinter Review
Had to redo urlbarBindings.xml's content to make the rtl UI look like it does now. So the XBL is now closer than the previous patches to what it currently looks like. A new .urlbar-frontcap-and-textbox hbox groups the favicon and other front children with the .autocomplete-textbox-container hbox. dropmarker, popupset, and children moved back out to top-level. Visually tested on Windows 7, OS X, and Ubuntu. One consequence is that the over-link no longer overlaps the dropmarker and stop-go-reload, because in rtl mode those are both at the left of the bar. We could include some ltr-specific code/styling so that the dropmarker and stop-go-reload are overlapped, but only as follow-up polish. (See comment 19 for more rtl discussion in case you missed it.)
Attachment #474895 - Attachment is obsolete: true
Attachment #475274 - Flags: review?(dao)
Comment on attachment 475274 [details] [diff] [review] reviewable patch 7 >+ case "transitionend": >+ if (aEvent.target == this._overLinkBox) >+ this._overLinkTransitioning = false; >+ break; also check aEvent.propertyName here. I haven't reviewed the test.
Attachment #475274 - Flags: review?(dao) → review+
For clarity, do you want to review the test before landing the patch?
(In reply to comment #112) > I presume this means gfx.font_rendering.directwrite.enabled set to false? I think that setting mozilla.widget.render-mode to 0 turns it off.
Keywords: checkin-needed
Whiteboard: [has patch] → [can land]
Addresses comment 120.
Attachment #475274 - Attachment is obsolete: true
http://hg.mozilla.org/mozilla-central/rev/0caec4ddff74
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [can land]
Depends on: 596587
Target Milestone: --- → Firefox 4.0b7
Depends on: 596644
Depends on: 596678
Depends on: 596779
Depends on: 596802
Depends on: 596884
Depends on: 596917
Depends on: 596921
If you're looking for user feedback: this feature is really annoying. My whole browsing experience is now full of constant distraction as things flicker on and off in the address bar. Can I have a preference to put it back in the status bar where I could ignore it until I wanted to know?
(In reply to comment #126) > If you're looking for user feedback: this feature is really annoying. > > My whole browsing experience is now full of constant distraction as things > flicker on and off in the address bar. Can I have a preference to put it back > in the status bar where I could ignore it until I wanted to know? The work on this needs to be polished, there are some fixes that need land. However putting it back in the status bar can't happen as the status bar has been commissioned. I'm sure there will be an add on to put it in the addon bar though.
Not that anybody cares, but this is all such a painfully dumb idea. If you desperately need to hate on the status bar so much, do https://bugzilla.mozilla.org/show_bug.cgi?id=541656 when it's turned off, like IE9 does it. Otherwise I might suggest that all ye Chrome feature thieves could just use Chrome instead of turning poor old Firefox into Chrome: Wannabe Edition. That would spare everybody involved a lot of effort, too.
Please stop commenting on what is better for you, this is not a challenge for who finds the best reasoning, this is a bug tracker. If you dislike the change move to mozilla.dev.apps.firefox and create a discussion thread there. If you have suggestion on how to improve the current experience go to mozilla.dev.usability and create a discussion thead there. Posting here is only causing you breaking our etiquette: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
This is a bug tracker where people can 'vote' that something is oh-so-important, so logically they must also be able to express the opposite. Your link explicitly mentions the very real possibility of "a heated debate going on", too. So no, not breaking that etiquette. There's no WONTFIX or INVALID going on here. It'd be a more useful use of anybody's time to improve browser stability with an arbitrary number of tabs, maybe testing with 1000, 1750, 2500, 4000, 7000, 10000. Stable browser = good browser; paining users with "location bar popup horribleness" just gets you users being all 'they should have "vote against" in the bugzilla'. P.S.: You also didn't *drumrolls* "make me aware of this document by private mail", hence you *drumrolls*.. don't follow the etiquette you linked. ^_^
(In reply to comment #130) > This is a bug tracker where people can 'vote' that something is > oh-so-important, so logically they must also be able to express the opposite. One thing I agree here is that it as always been confusing for me to know if Bugzilla is for the patching process or both ideas (of improvements, ...) discussion and patching process. I've filled bug 597020 for this.
(In reply to comment #129) > Posting here is only causing you breaking our etiquette: > https://bugzilla.mozilla.org/page.cgi?id=etiquette.html (In reply to comment #130) > P.S.: You also didn't *drumrolls* "make me aware of this document by private > mail", hence you *drumrolls*.. don't follow the etiquette you linked. > ^_^ Ha! I didn't remember there was a line to that effect in there. :p Posting a link to the Bugzilla etiquette page in a bug that has, shall we say, gone off track, has become standard procedure in recent years. It's sort of like quoting the Riot Act. The irony of this standard procedure being in conflict with the document itself, and rarely anyone noticing it, is hilarious. Someone should really update that page to say that normally users should use private mail to quote etiquette but us Bugzilla residents will sometimes post it in a bug so that the multiple people causing the problems can all see the link at once, including future would-be posters. (In reply to comment #127) > However putting it back in the status bar can't happen as the status bar has > been commissioned. He meant decommissioned, just to be clear. The status bar is slated for removal.
No longer depends on: 596884, 596917
Isn't there any option to disable it? I cannot see the whole url when it is long. I use status bar for this. My suggestion: Make view status bar default. On hyperlink hover show the target url in the status bar. Show the domain name in black, and the rest in grey.
If you want to see the url you have to move your eye to the right (other left) part of the address bar. If the url is short you start to reed to from far right, if the url is long you start to read the url from about the middle of the url bar. Because of that (different lenghts of urls) it is mind blowing and eye unfriendly to read the url. "Move your eye to right, no, it long move to middle. Now another url, where should I moe my eye to right side or middle? Umm, now lets try to middle, nooo, it is in the right very right side, I was disappointed." Annoying! User friendly? No. It is user unfriendly. By the way, some people stated somewhere that the status bar is going to be removed. It is very bad idea! Why? One day I'm surfing on the internet and almost all the pages on the internet are still loading even after a minute. Then looking to the status bar I see that analytics.google.com is in still loading presses. Which helped me to realize that the problem was with google analytics, notging related to my computer. Thanks to the Status Bar!
Please look at the bugs this depends on (at the top of the page) before commenting. That's already being addressed in Bug 596587.
Verified fixed. Please file any follow ups in separate bugs. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100916 Firefox/4.0b7pre
Status: RESOLVED → VERIFIED
Depends on: 597338
Depends on: 597382
Depends on: 597581
Depends on: 597771
Depends on: 597841
Depends on: 597896
Depends on: 596698
Depends on: 597930
This is such of a compromised bad decision I cannot begin to describe it in any scale terms. It's almost humorous how designers try to explain and justify their design choices with a quasi-aesthetic logic then just ignore that logic when something doesn't fit. This change is purely due to the removal of the status bar. There was a substantial blog post explaining how the designers approached the question of removing the status bar and the only thing they could not answer was how to replace the fundamental URL preview on hover. Now they come up with this extremely bad compromise that is entirely dependent on horizontal screen space and will therefore be constantly compromised for long URLs. Why even get rid of the status bar in the first place? To replace it with an extension bar! Yes that's right, the entire "we need more screen space" logic is complete ****. Look at the examples in the Jetpack SDK and you will see that panels are even 'taller' than the status bar!
Hello please make it possible in the options or about:config to use the old status bar behavior! Thanks
Status bar will be gone and replaced with Addons bar. See Bug 574688. Addon writers can easily add the old functions to the new Addons bar, and i believe, they will do that.
My opinion on this is that now when hovering a link: - I can see less of the target URL than I can in other browsers (including Fx 3.6) - I can see less of the current URL than I can in other browsers (including Fx 3.6) I don't think the advantages outweigh these 2 points. This is especially true when you take into account that specially crafted pages could permanently display a link target in the location bar obscuring the current location to some extent. With a long domain, a long target URL and an average or small screen size won't this compromise security to some level?
Depends on: 598451
Depends on: 598461
No longer depends on: 598461
(In reply to comment #141) > My opinion on this is that now when hovering a link: > > - I can see less of the target URL than I can in other browsers (including Fx > 3.6) This is only a problem for very long URLs, very low screen resolutions/window size, or a combination of both. I'm not saying it is a non-issue, but I wouldn't expect it to be a common problem. There have been ideas to intelligently shorten the URL, and there is room for improvement here. > - I can see less of the current URL than I can in other browsers (including Fx > 3.6) This doesn't matter while you're hovering a link. Take your cursor off the link to see the current URL. > I don't think the advantages outweigh these 2 points. > > This is especially true when you take into account that specially crafted pages > could permanently display a link target in the location bar obscuring the > current location to some extent. With a long domain, a long target URL and an > average or small screen size won't this compromise security to some level? The current URL always occupies a certain percentage of the location bar. This is not possible from what I can tell, no matter how small the window becomes. The design has been considered to some extent to communicate that the hover URL is not the current URL – grayed text, arrow-divider. (In reply to comment #138) > This is such of a compromised bad decision I cannot begin to describe it in any > scale terms. It's almost humorous how designers try to explain and justify > their design choices with a quasi-aesthetic logic then just ignore that logic > when something doesn't fit. Sorry you're having trouble understanding the reasons behind these changes. A lot of thought and discussion goes into Firefox UI changes. They aren't arbitrary. > This change is purely due to the removal of the status bar. There was a > substantial blog post explaining how the designers approached the question of > removing the status bar and the only thing they could not answer was how to > replace the fundamental URL preview on hover. Now they come up with this > extremely bad compromise that is entirely dependent on horizontal screen space > and will therefore be constantly compromised for long URLs. If "they" couldn't answer how to replace the URL preview, how was this solution decided on? As I recall, a few options have been discussed – location bar preview, Safari-style tooltip, and Chrome-style status bar on hover. The location bar preview has some advantages over the others, not the least of which being a better UI hierarchy. I have been following Firefox UX design for years and have constantly been floored by the genius and ability of this team to abstract design issues to a level that allows for meaningful, intelligent discussion and exploration of what is the best evolution of Firefox's UI design. Sometimes changes don't feel right, but when the justification behind them is understood they cannot be denied. > Why even get rid of the status bar in the first place? To replace it with an > extension bar! Yes that's right, the entire "we need more screen space" logic > is complete ****. Look at the examples in the Jetpack SDK and you will see > that panels are even 'taller' than the status bar! So, from your perspective, the status bar and extension bar are apples-to-apples. What's the complaint, then? There will surely be an extension to add URL preview to the extension bar.
Depends on: 599686
Depends on: 599827
Depends on: 600635
> There will surely be an extension to add URL preview to the extension bar. https://addons.mozilla.org/ru/firefox/addon/235283/ [Status-4-Evar] does this :]
No longer depends on: 599686
Depends on: 601060
Depends on: 601412
No longer depends on: 601412
How user can disable links in addressbar? Bring links in my statusbar back (ghhrm... @#&$#...)! I support comments #128 and #141! For the slightly convenience (which i could not realize yet) you breaking up user experience, which is much worse case!
First, please read the bugzilla etiquette document https://bugzilla.mozilla.org/page.cgi?id=etiquette.html Second, the answer to your question is in the comment right above yours. https://addons.mozilla.org/ru/firefox/addon/235283/
Just for the sake of it not always showing in Russian, here's a similar link but locale and application agnostic: https://addons.mozilla.org/addon/235283/
Matthew, can you see anything impoliteness in my statements? Take my apologise then. I'm a biggest fan of FF for years (from phoenix) and i dont like this new awesomeness feature. Other browsers just displaying the statusbar, at the bottom of screen. It easing a transition for new users from other browsers to FF. And i dont want the links mess in address bar. Why does the user have to guess about any links shortenings and why do not displaying the whole link url and the page address separately from each other. As a secutiry it consider easer links spoofing,xss etc. Another kind of problem is absence of "loading from" messages. In previous version of ff, some site loading anything from http://some.malware.domain - i notice that. Dave, Thanks, but https://addons.mozilla.org/addon/235283/ doesn't work for me. It hides url from addressbar but doesnt show it at statusbar. The addon http://en.design-noir.de/mozilla/linktarget-display/ does the trick, but with a big latency, like Chrome, and doesnt work while page loads. That i want - is immediately showing the urls at bottom then i targetting it. And the loading progress if possible.
(In reply to comment #147) > Matthew, can you see anything impoliteness in my statements? (In comment #145) > First, please read the bugzilla etiquette document > https://bugzilla.mozilla.org/page.cgi?id=etiquette.html You were quite polite, but that's not the same thing as etiquette.
Ok, Dave, i've just read it, and i doesn't found which part of rules i break. In every my comment i have constructive arguments about my user experience. So can you please not teaching me etiquette anymore - doing so you breaking the rules. > If you see someone not following these rules, the first step is, > as an exception to guideline 1.4, to make them aware of this > document by _private_ mail. > Flaming people _publically_ in bugs violates guidelines 1.1 and 1.3.
(In reply to comment #147) > https://addons.mozilla.org/addon/235283/ doesn't work for > me. It hides url from addressbar but doesnt show it at statusbar. The add-on does both the page loading and hover link text. Drag its widgets to the new add-on bar from the toolbar layout/customization dialog and update the add-on preferences.
Oh, perfect! Thanx Dennis. It's actually works. As much as i like. I used to open "customize toolbar" screen, and drag the needed items to statusbar. Thats how it's done! =)
(In reply to comment #149) Going in circles... Read comment 132. Simply put: this is not a forum. This bug is done; no more comments please. All further discussion belongs elsewhere. If you have a new bug, file a new bug. If you want more discussion, post in the groups.
Depends on: 603883
Attached file URL spoof test case 1 —
This test case shows how one can easily spoof the visual identity of a link. No javascript is needed.
Attached file URL spoof test case 2 (obsolete) —
This spoof uses javascript to take the user to a different link than what is displayed in the URL bar. This is really nothing new, but demonstrates how easily it can be abused.
Attached file URL spoof test case 3 —
Similar to test case one, however this really takes the annoyance to an all new level.
Eric, what is the context of these examples? Were all these things impossible before the move of the URL preview? If so, file a new bug please and make it block this.
All the testcases are somewhat valid before this bug as well, although now they are more prominently displayed and more prone to spoofing under normal circumstances. The only real legitimate testcase is the first, and to address it, we should either show the "%20"s in the location bar on hover or delete them (when there's more than a single whitespace character in a row). The first option sounds more correct. Can you file a followup bug and set it to block this one?
Eric, please don't post a bunch of stuff to a verified fixed bug. File a new bug report for a new bug please. That's pretty much the point of Bugzilla. (I'm going to obsolete all those files, as the don't belong here)
Attachment #489529 - Attachment is obsolete: true
Attachment #489531 - Attachment is obsolete: true
Attachment #489534 - Attachment is obsolete: true
Sorry, I won't post any more examples of a target not being displayed where it's intended.
(In reply to comment #159) > Sorry, I won't post any more examples of a target not being displayed where > it's intended. But if you think it's a valid issue, please file a new bug on it: https://bugzilla.mozilla.org/enter_bug.cgi?blocked=587908&component=Location%20Bar&product=Firefox&version=Trunk
Depends on: 612828
Depends on: 613390
Depends on: 613357
No longer depends on: 596587
Something that I don't think has been mentioned here is the muscle memory associated with looking at link destinations. I suspect that most people here are using betas or trunk almost all of the time. I spend almost equal amounts of time between current browsers (3.6/IE/Chrome) and nightlies (at home) and the experience is painful. This will be the case for many people who at home will accept the major update when it is offered, but at work/university cannot update the installed version (or use another browser where the link destination is displayed in the usual location). In general I feel that the amount of effort required by a long term user to adapt to UI/UX changes has been underestimated for the sake of idealistic design. Some of these habits will be more than a decade old. Please let me know if I'm wrong. Here are some Input searches that show many people commenting on the change. You can spot when b7 was released, and judging by the initial influx of messages, this change is immediately noticeable (presumably when a user looks for the link destination and it's not there). http://input.stage.mozilla.com/en-US/beta/search?product=firefox&version=&date_start=&date_end=&q=status+bar http://input.stage.mozilla.com/en-US/beta/search?product=firefox&version=&date_start=&date_end=&q=statusbar http://input.stage.mozilla.com/en-US/beta/search?product=firefox&version=&date_start=&date_end=&q=hover+link http://input.stage.mozilla.com/en-US/beta/search?product=firefox&version=&date_start=&date_end=&q=link+location http://input.stage.mozilla.com/en-US/beta/search?product=firefox&version=&date_start=&date_end=&q=link+destination http://input.stage.mozilla.com/en-US/beta/search?product=firefox&version=&date_start=&date_end=&q=link+preview http://input.stage.mozilla.com/en-US/beta/search?product=firefox&version=&date_start=&date_end=&q=link+target http://input.stage.mozilla.com/en-US/beta/search?product=firefox&version=&date_start=&date_end=&q=target+URL
(In reply to comment #161) > Something that I don't think has been mentioned here is the muscle memory > associated with looking at link destinations. > > I suspect that most people here are using betas or trunk almost all of the > time. I spend almost equal amounts of time between current browsers > (3.6/IE/Chrome) and nightlies (at home) and the experience is painful. This > will be the case for many people who at home will accept the major update when > it is offered, but at work/university cannot update the installed version (or > use another browser where the link destination is displayed in the usual > location). In general, I agree with you. There is indeed a breakage of muscle memory, and that could be painful if you often have to switch between 3.6 and 4.0, but I wonder how often that actually happens—especially at this point, when those using the nightlies already know to suck it up when this stuff happens. I recently had the experience myself, when switching back to my old computer, which is still running 3.6. But the thing was, my muscle memory had already changed: I found myself looking up to the URL bar, because I forgot that the target was still displayed int he status bar. I think the only people who have a problem will be those who have to switch between 3.6 and 4.0 repeatedly. Everyone else's muscle memory will change rather quickly; they'll get used to it.
(In reply to comment #161) > In general I feel that the amount of effort required by a long term user to > adapt to UI/UX changes has been underestimated for the sake of idealistic > design. Some of these habits will be more than a decade old. The thing is, you could say the same about the changes to the location bar in Firefox 3.0 (aka. "AwesomeBar"). Sometimes changes that are initially seen as controversial end up being the norm a few years later. Safari, Chrome, Opera all ship an AwesomeBar equivalent at this point, but when it came out, there was a lot of people that just hated it, said they would switch browsers because of it, etc. There are several follow-up bugs that improve most of the current issues with the link preview — and we're certainly aware that it isn't complete yet — bug 613390 is the meta-bug with the associated fixes marked as dependent bugs. Both the Firefox team and the UX team have been living with this change for a while now, and although there is an initial "OMG it changed" period for a few days, most people seem to like the new behavior better once they get used to it. And again, there are multiple improvements coming that make it even better, see bug 613390.
(In reply to comment #162) > I think the only people who have a problem will be those who have to switch > between 3.6 and 4.0 repeatedly. Everyone else's muscle memory will change > rather quickly; they'll get used to it. I agree that it didn't take too long to adapt when using the same version consistently. This is part of the reason that it is then hard to use another browser (3.6/IE/Chrome) because the memory has changed. I guess this could be applied to other changes where there isn't a consistency between 2 versions (the home button position for example) but this is the one that was most noticeable to me. I think this is because it is a very common action, and that it isn't just Firefox < v4 that has the target in the bottom left, but other browsers as well (whereas you might expect the home button to be in a different place when using a different browser). (In reply to comment #163) > The thing is, you could say the same about the changes to the location bar in > Firefox 3.0 (aka. "AwesomeBar"). Sometimes changes that are initially seen as > controversial end up being the norm a few years later. Safari, Chrome, Opera > all ship an AwesomeBar equivalent at this point, but when it came out, there > was a lot of people that just hated it, said they would switch browsers because > of it, etc. I think there are a few differences. The main one is that the AwesomeBar is adaptable. After only a couple of selections, you can get back to the old behaviour if you want to. The other difference (more subjective) is that I agree that the AwesomeBar is better once you've got used to it, but I don't really feel the same about this (comment 141). > Both the Firefox team and the UX team have been living with this change for a > while now, and although there is an initial "OMG it changed" period for a few > days, most people seem to like the new behavior better once they get used to > it. And again, there are multiple improvements coming that make it even better, > see bug 613390. I don't doubt that the team are eating their own dogfood, what I was questioning is how many people have tried living with both versions at once. I know many institutions that won't upgrade until 3.6 is end-of-lifed whereas the users may be using 4 at home. I do think that the intended fixes will help. I'm just not sure all of the work and the disadvantages are worth the advantages. I'll leave it there.
Depends on: 629024
Problem: In full screen mode I now can't view link targets.
Depends on: 630608
(In reply to comment #164) > I don't doubt that the team are eating their own dogfood, what I was > questioning is how many people have tried living with both versions at once. I've been eating the "dogfood" for months (Minefield is my default browser) and I like it. I deal with Chromium and IE7 at the same time and even when I disliked this *new* and *improved* UI I've grown to love it. Now *all* location information is in the *location* bar. How cool is that? Now if people like Chromium behavior (bug 541656) 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. (In reply to comment #165) > Problem: In full screen mode I now can't view link targets. Filed bug 630608
I'm afraid I think the link/loading info in the location bar is just very bad idea from an anatomical and linguistic POV. The head naturally tilts downwards as do the eyes, in addition to the fact that as an speaker of an Indo-European language my eyes are naturally drawn to the left, reading from right to left, so the natural place for something I need to regularly look at should be the lower left- people who put it there in the first place didn't do without reason. I fear that the drive to put all the info in the location bar is driven more by the need to do something new or different to other browsers, which should not really be the driving factor in deciding what is a 'good' idea.
By that argument, the entire location bar would be at the bottom of the screen. If you have to lift your head to see the location bar then your chair is too low, your screen to high (to big?) or both. I've always used computers where the top of the screen was basically eye level both at home and in office environments.
Per bug 541656 looks like this would be gone shortly =( Can somebody please turn it into an add-on or something like that, please?
It will be added to Status-4-Evar
Depends on: 631184
Attachment #489529 - Attachment is obsolete: false
Comment on attachment 489534 [details] URL spoof test case 3 Re-enabling 2 of Eric Coleman's testcases that were obsoleted in comment 158. Although link spoofing has always been possible, the link previews never previously obscured part of the current location, so for that reason I think they are valid. They should maybe have been part of another bug, but that bug isn't going to be filed, so they are now here for posterity.
Attachment #489534 - Attachment is obsolete: false
Is the behavior in Minefield prebeta 12 [link preview in bottom left tooltip] going to be the default link preview in Firefox 4? A user's two cents: I found it much easier to transition from the status bar to the URL bar between Fx3.6 and Fx4beta than I did this time around [Fx 4 prebeta 11 to prebeta 12].
(In reply to comment #172) > Is the behavior in Minefield prebeta 12 [link preview in bottom left tooltip] > going to be the default link preview in Firefox 4? > > A user's two cents: I found it much easier to transition from the status bar to > the URL bar between Fx3.6 and Fx4beta than I did this time around [Fx 4 prebeta > 11 to prebeta 12]. Yeah, according to the powers that be they can't get it done for FF4 so they won't even make it an about:config option like the inspector is (the right way to handle this IMO). It's all a huge pain to have this information going into the right place then being taken out again last minute.
Is there any further discussion to be had, or is this a final decision? The link preview in the URL bar made sense to me, and I hope this is still something that may be altered in the future. If not, here's to hoping someone makes an extension soon to put the link preview back in the URL bar.
wtf? i was just getting used to it as one of the best decisions. now the link target widget looks like a cheap chrome ripoff instead of the more logical one in the address bar. about:config is too hidden, this should be an option in the advanced pane instead.
No longer depends on: 648780
No longer depends on: 629024
Dependent bugs are being closed. Does that mean it's been decided to never do this and just go with the "quick fix" popup method?
(In reply to patrickjdempsey from comment #176) > Dependent bugs are being closed. Does that mean it's been decided to never > do this and just go with the "quick fix" popup method? I just closed one and all the others that are direct parts of this implementation should probably be closed out as invalid (at least for the time being; any new attempt at this would probably start in a new bug). I'm not going to make that decision, though; someone else can close them all out if they feel it's needed.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: