User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:2.0b6pre) Gecko/20100907 Firefox/4.0b6pre Build Identifier: Mozilla/5.0 (Windows NT 6.0; rv:2.0b6pre) Gecko/20100907 Firefox/4.0b6pre The button is green even when there's nothing typed in URL bar. Confusing because clicking GSR button when the URL bar is empty won't go anywhere. Reproducible: Always Steps to Reproduce: 1. Open a new tab or window(show a blank page). Actual Results: The button is green even when there's nothing typed in URL bar. Expected Results: IMHO button should turn green once there's, at least, one typed character in the URL bar.

I just followed the Firefox 3.6 behavior when implementing this. The go button appeared whenever the url bar textbox had been edited or did not match the current url, regardless of its emptiness. UX team, input?

I think original behavior makes sense. What else are we gonna put in place of it? Reload? Stop? Both of those make even less sense. At least the Go button makes it seem like you're about to "Go" somewhere with the new tab and Fx is waiting for you.

How about a "grayed out go" when the URL bar is empty or unchanged? Another behavior I find funny is coming back to a new tab/window with an empty URL bar, you'd be greeted by a "reload" button that wouldn't do anything either. I think this also can be prevented if the empty/unchanged case is properly handled.

(In reply to comment #3) > How about a "grayed out go" when the URL bar is empty or unchanged? > Another behavior I find funny is coming back to a new tab/window with an empty > URL bar, you'd be greeted by a "reload" button that wouldn't do anything > either. > I think this also can be prevented if the empty/unchanged case is properly > handled. This will be fixed in bug 565575 by making sure the url bar is focused. Displaying a disabled (ghosted) go button makes sense to me.

I also think the way it works makes sense and is fine.

I agree with comment 5, it works fine as is.

>The go button >appeared whenever the url bar textbox had been edited or did not match the >current url, regardless of its emptiness. > >UX team, input? Having the button appear on first edit should help users understand what it is for more. After they type a single character the button will appear, and that sequence means "I can perform an action on the thing you just entered." Also, I agree with comment #0 that hitting go when everything is blank is a bit strange.

(In reply to comment #7) > Having the button appear on first edit should help users understand what it is > for more. After they type a single character the button will appear, and that > sequence means "I can perform an action on the thing you just entered." Also, > I agree with comment #0 that hitting go when everything is blank is a bit > strange. Agreed. It shouldn't indicate that something works when it doesn't do anything. Go button being ghosted/white bg until something has been entered makes sense, combined with the fix in bug 565575 (adding as dependency for this one).

Also note that while a new tab shows the green go button right after it is created, switching to another tab and back to the new one (with nothing inside the entry) now shows the reload button

(In reply to comment #9) see comment 3 and comment 4.

>Go button being ghosted/white bg until something has been entered makes sense We are using this appearance for active but not hovered (like reload), so I think the best way to go would be for the go button to simply not exist when it is inactive.

(In reply to comment #11) > We are using this appearance for active but not hovered (like reload), so I > think the best way to go would be for the go button to simply not exist when it > is inactive. What would be displayed then, if neither go, reload, nor stop doesn't make sense?

we would display a very zen nothingness (well, the drop down arrow would still be there until the user entered something)

(In reply to comment #13) > we would display a very zen nothingness (well, the drop down arrow would still > be there until the user entered something) +1 Paired with bug 587901, comment 50 and we'd end up with a beautiful empty "awesome bar" =)

(In reply to comment #11) > >Go button being ghosted/white bg until something has been entered makes sense > > We are using this appearance for active but not hovered (like reload), so I > think the best way to go would be for the go button to simply not exist when it > is inactive. I guess there are now 5 different states of go/stop/reload button: 1. Normal 2. Hover 3. Pressed and these three are from this mockup: https://wiki.mozilla.org/images/8/82/Firefox-4-Mockup-i05-(Win7)-(Aero)-(TabsTop)-(ButtonStates).png 4. Reload with white bg when not hovered 5. Grayed stop for a short time after loading a page I suggest to make grayed go button, analogous to the grayed stop.

(In reply to comment #13) > we would display a very zen nothingness (well, the drop down arrow would still > be there until the user entered something) I'll make a patch for this.

Unassigning myself, since I've got a ton on my plate already. Looks like a good second bug ;P

(In reply to comment #11) > >Go button being ghosted/white bg until something has been entered makes sense > > We are using this appearance for active but not hovered (like reload), so I > think the best way to go would be for the go button to simply not exist when it > is inactive. That's what I meant by saying "white bg" — sorry for the lack of clarity here. So we agree completely, the button shouldn't show up at all until some text has been entered.

Comment on attachment 498901 [details] [diff] [review] patch Broken cases: 1. Have some text in the url bar. 2. Press ctrl/cmd+t. 3. Go button is there but shouldn't be. 1. Have some text in the url bar. 2. Select all; cut. 3. Go button is there but shouldn't be. It seems like onInput does not cover all the cases we need. Getting it right in only some cases makes it unpredictable, which is worse than the current experience. FWIW, the disappearance of the button feels quite jumpy. :\ Let's get UX people to try this out first-hand.

Correction: 1. Have some text in the url bar. 2. Click in the url bar to focus the textbox. 3. Press ctrl/cmd+t. 4. Go button is there but shouldn't be.

(In reply to comment #20) > Comment on attachment 498901 [details] [diff] [review] > patch Anyway I can help to review this?

(In reply to comment #22) > (In reply to comment #20) > > Comment on attachment 498901 [details] [diff] [review] > > patch > > Anyway I can help to review this? The patch doesn't work properly, as Frank pointed out above, so it still needs work before it can be reviewed. I stopped working on this because it's not blocking Firefox 4. If you have time and energy to work on it, feel free to take it from me! :)

(In reply to comment #23) > I stopped working on this because it's not blocking Firefox 4. If you have > time and energy to work on it, feel free to take it from me! :) I probably have the energy, but not the time nor the skill =( In any case, if you're not actively pursuing this, can you please release the "Assigned To:"?

(In reply to comment #24) > (In reply to comment #23) > > I stopped working on this because it's not blocking Firefox 4. If you have > > time and energy to work on it, feel free to take it from me! :) > > I probably have the energy, but not the time nor the skill =( > In any case, if you're not actively pursuing this, can you please release > the "Assigned To:"? I'm unassigning myself, but you could have just done that by making yourself the assignee :) If you decide to work on this and find you have trouble, you can ask me questions.

(In reply to comment #25) > I'm unassigning myself, but you could have just done that by making yourself > the assignee :) If you decide to work on this and find you have trouble, you > can ask me questions. If my "bugzilla fu" is that low, imagine my "hacking fu" =) I've filed bug 656002 that might be related as "Reload Tab" is visible on about:blank and about:home pages that as far as I understand are static and shouldn't show a reload option IMHO.

How can I put this one on http://areweprettyyet.com/4/mainWindow/ ?

this is more of an interactive bug than visual polish issue, but either way we should get around to fixing it.

Now that there's no more big green button, this doesn't strike me as much of a problem anymore (it's definitely not distracting). When we were working on this before, I remember making the button disappear felt jumpy, so I propose we WONTFIX this.

The fact is the "button" is still there and does nothing. Also if you move the focus from the URL bar to anywhere in a "new tab" the go button changes to a "reload" one that still does nothing. Same for the new "globe" on the left of the URL bar. All this "odd" behavior might be misconstrued as "broken" as you're giving users affordances that do nothing. IMHO the only affordance that makes sense in the URL bar on about:newtab is the down arrow as it actually does something. I believe it "felt jumpy" because the icons in the URL bar are ordered "incorrectly" IMHO. Icons on the right hand side of the URL bar should be ordered go/reload, favorite star, down arrow. Go appears only when there's something typed in the URL bar and is the one closer to the typed URL as it allows one to act on it. Favorite star only appears when there's a page loaded, this already appears "magically" today. Down arrow is in there permanently on the right hand side as it is usable on every state of the URL bar and also resembles a "combo box" that gives the user access to the "world wide web". Hope it all made sense =)

Updated the summary to reflect comment 31 and added some blocks that I believe make sense.

Comment 31 are just random thoughts about loosely related stuff.

¡Hola! I believe https://bugzilla.mozilla.org/show_bug.cgi?id=1346488 fixed this somewhat accidentally. ¡Gracias! Alex