594050 - Hide go button when url bar is blank in blank tab

Status: RESOLVED WORKSFORME

(Firefox :: Theme, defect)

Description

[alex_mayorga]

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.

Comment 1

[Frank Yan (:fryn)]

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?

Comment 2

[Benjamin Xiao]

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.

Comment 3

[alex_mayorga]

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.

Comment 4

[Frank Yan (:fryn)]

(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.

Comment 5

[Gary [:streetwolf52]]

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

Comment 6

[Gary King]

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

Comment 7

[Alex Faaborg [:faaborg] (Firefox UX)]

>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.

Comment 8

[Alex Limi (:limi) — Firefox UX Team]

(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).

Comment 9

[Michael Monreal [:micmon]]

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

Comment 10

[Frank Yan (:fryn)]

(In reply to comment #9)

see comment 3 and comment 4.

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

>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.

Comment 12

[Frank Yan (:fryn)]

(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?

Comment 13

[Alex Faaborg [:faaborg] (Firefox UX)]

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

Comment 14

[alex_mayorga]

(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" =)

Comment 15

[naga_maga]

(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.

Comment 16

[Frank Yan (:fryn)]

(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.

Comment 17

[Frank Yan (:fryn)]

Unassigning myself, since I've got a ton on my plate already.

Looks like a good second bug ;P

Comment 18

[Alex Limi (:limi) — Firefox UX Team]

(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 19

[:Margaret Leibovic]

Attachment: patch

Comment 20

[Frank Yan (:fryn)]

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.

Comment 21

[Frank Yan (:fryn)]

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.

Comment 22

[alex_mayorga]

(In reply to comment #20)
> Comment on attachment 498901 [details] [diff] [review]
> patch

Anyway I can help to review this?

Comment 23

[:Margaret Leibovic]

(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! :)

Comment 24

[alex_mayorga]

(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:"?

Comment 25

[:Margaret Leibovic]

(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.

Comment 26

[alex_mayorga]

(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.

Comment 27

[alex_mayorga]

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

Comment 28

[Alex Faaborg [:faaborg] (Firefox UX)]

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

Comment 30

[:Margaret Leibovic]

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.

Comment 31

[alex_mayorga]

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 =)

Comment 32

[alex_mayorga]

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

Comment 33

[Dão Gottwald [:dao]]

Comment 31 are just random thoughts about loosely related stuff.

Comment 34

[alex_mayorga]

¡Hola!

I believe https://bugzilla.mozilla.org/show_bug.cgi?id=1346488 fixed this somewhat accidentally.

¡Gracias!
Alex