Closed Bug 593293 Opened 14 years ago Closed 13 years ago

pixel pushing and polishing for the new combined location bar

Categories

(Firefox :: Theme, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 684450
Tracking Status
blocking2.0 --- .x+

People

(Reporter: fryn, Assigned: shorlander)

References

Details

(Whiteboard: [arewepretty-add])

Attachments

(2 files)

time to nudge those darn little dots into their correct locations for the final release. a couple things that I'm already aware of: 1. from bug 544816 comment #60: https://bug544816.bugzilla.mozilla.org/attachment.cgi?id=471762 2. at least on OS X, we'll need to add width: 30px or something like that to adjust the width of the combined stop/go/refresh button. shorlander, anything else you see in need of some visual polish?
blocking2.0: --- → ?
Component: Toolbars → Theme
QA Contact: toolbars → theme
Is this polishing? The button turns green even when there's nothing typed in the URL bar, confusing as if you click it when the URL bar is empty it won't take you anywhere. IMHO it should turn green once there's at least one character in the URL bar.
Attached image Mockup SRG on the left (deleted) —
Stop-reload-go next to the navigation buttons but inside the location bar (left).
I do think that it would be more sensible to move the SRG button to the left and Larry next to it. Also the button should be a bit bigger (wider). The point of putting it to the left is that from my experience users tend to use Enter for what the Go button does but very often use the Reload button rather than F5. Putting the SRG button close to the back forward buttons makes the GUI more intuitive regarding the way the typical user uses the GUI. Mockup of SRG on the left side of location bar: https://bugzilla.mozilla.org/attachment.cgi?id=471836
You can put it there yourself.
(In reply to comment #0) > time to nudge those darn little dots into their correct locations for the final > release. > > a couple things that I'm already aware of: > > 1. from bug 544816 comment #60: > https://bug544816.bugzilla.mozilla.org/attachment.cgi?id=471762 > > 2. at least on OS X, we'll need to add width: 30px or something like that to > adjust the width of the combined stop/go/refresh button. > > shorlander, anything else you see in need of some visual polish? - Width on OS X is off by 1px - Width on Windows is off by 2px - I am not seeing the 1px height problem from bug 544816 comment #60
(In reply to comment #5) > You can put it there yourself. No you can't. Have you watched the Mockup I posted? It's not possible without a userstyle.
the customize… dialog is quite akward for every non-geek person: Putting the cancel button left to the reload button results in both buttons being shown where as if you put the cancel button to the right it combines with the reload button. Only if you put it right of the location bar and press done it transform in its combined location bar look. Maybe there’s some way to make this easier to understand for normal users. And I know it may be difficult and annoying to implement at such a late stage, but I am on Morpogs side on this that you should at least make it an option to put the SRG button on the left of the location bar.
Depends on: 593640, 593684
Depends on: 593350
Depends on: 593392
Lacking a dedicated Windows and Linux machine on which to build and test theme changes, I likely won't be able to fix these in time for Firefox 4, so I'm unassigning myself. Shorlander, can you look at this and the dependent bugs?
Assignee: fryn → nobody
(In reply to comment #3) > Created attachment 471836 [details] > Mockup SRG on the left Interesting, though it also seems like an odd location. FWIW, the two biggest issues I've had after using the new stop/go/reload button so far are: 1) Smaller, less visually distinct click target. Combined with muscle-memory for the old location, this will take some more time to get used to. 2) Awkward interaction. While I don't use stop/reload all that much, I've noticed that when I _do_ it's part of a "stop this load, go back to the previous page", so I'm clicking the Back button and it's a much large mouse movement to get to it now. For example, after clicking on the wrong link and I catch it before the browser has loaded the new page. I wonder if our Test Pilot data shows this as a common pattern when Reload is invoked, it's an interesting case where a less-used function (stop) is noticeably slower to use due to the two actions being used as a pair.
I have to agree with both points, I use stop and back a lot but also reload after clicking a tab in the tab bar which i have on the left (I realize this is currently not possible without an add-on, but it doesn't hurt to mention it). So for me it's currently too far away and too small.
Shouldn't clicking back or forward on a currently loading page automatically stop the loading of the current one immediately and then go to the other page?
(In reply to comment #2) > The button turns green even when there's nothing typed in the URL bar Filed bug 594050.
Depends on: 594050
Attached image SGR state comparison (deleted) —
Arrow for Go state on Mac has more weight than reload or stop glyphs. Reducing its size to the same as the awesomebar dropdown arrow would make it a little lighter and would be more consistent visually, especially considering those two arrows are so close to each other.
Given all the dependent bugs, this could turn into a meta-bug. Or are you planning on a megapatch for this fryn? (i'd prefer splitting patches across dependent bugs - easier to track, less easy to regress, etc, but it's up to you)
No longer depends on: 593640
I will probabl(In reply to comment #16) > Given all the dependent bugs, this could turn into a meta-bug. Or are you > planning on a megapatch for this fryn? (i'd prefer splitting patches across > dependent bugs - easier to track, less easy to regress, etc, but it's up to > you) I will probably end up editing the CSS for this, which can likely all be handled in this bug. Anything outside the scope of image/CSS tweaks should probably be split into their own bugs. As I go down the list of things mentioned here I can file new bugs as needed.
(In reply to comment #16) > Given all the dependent bugs, this could turn into a meta-bug. Or are you > planning on a megapatch for this fryn? (i'd prefer splitting patches across > dependent bugs - easier to track, less easy to regress, etc, but it's up to > you) It's up to shorlander (see comment 10).
I think shorlander says he's taking this blocker. Woot!
Assignee: nobody → shorlander
blocking2.0: ? → final+
Depends on: 597675
Notes from the Grand Retriage: shorlander says it doesn't block, could be fixed later on branch
blocking2.0: final+ → .x
Whiteboard: [arewepretty-add]
Does bug 647948 fit here?
No longer depends on: 594050
Stephen streamlined the location bar icons, so we're done here.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Resolution: FIXED → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: