52036 - Classic: 'Go' and 'Search' buttons inconsistent w/ other buttons

Status: RESOLVED EXPIRED

(SeaMonkey :: Themes, defect)

Description

[gary_Cope]

Using 2000090808 win98 build.

Both these buttons need their look refining so they arent such an eyesore.
Currently they look like theyre placed there with not much thought for design,
their appearance improves slightly on mouseover where they more resemble
buttons. Width and height are out of proportion with the rest of buttons on this
bar.

Doesnt present a very nice image of the browser with M18/PR3 approaching.

Comment 1

[Doron Rosenberg (IBM)]

--> themes, classic keyword

Comment 2

[John Dobbins]

I filed bug 49912 regarding the search button only. The go button was still 
inside the url field at the time.
Both these buttons look funny because they were sized to fit in the url field. 
now that they would look better if they were changed from button-toolbar-3 to 
button-toolbar-2. (line 303 and 306 of navigator.xul)
In the Classic skin this would result in all the buttons matching. An Icon would 
need to be created for the go button.
In the modern skin search and go would then match the print button. Icons would 
have to be created for go and search.
I tried these changes with the search button before submitting bug 49912. An 
icon for Blue's search button is attached to 49912. (It was modern then).
IMHO these simple changes make both skins look better, along with most third 
party skins.

Comment 3

[Stephan Litke]

Attachment: navbar redesign

Comment 4

[Stephan Litke]

the Go, Search and Print buttons should be simple buttons (like Stop or Reload)
and there should be an option to turn of the text from the buttons, or, if there
is no option, the buttons should be picture-only buttons. Have a look at the
attachment above. I did some wild patchwork with linux version of Mozilla and
exchanged nearly all (Windows-stil) buttons ... And I'm happy now :) 

I think, the navigation bar needs a redesign, it looks urgly. At least for Linux
users, because the Linux Navigator 4 looks allready different...

Comment 5

[Asa Dotzler [:asa]]

setting bug status to New.

Comment 6

[hangas]

Sending to Hewitt.

Comment 7

[Joe Hewitt (gone)]

*** Bug 43734 has been marked as a duplicate of this bug. ***

Comment 8

[Ben Bucksch (:BenB)]

I disagree that Go and Search should be moved from the urlbar to the normal toolbar.

The reason is *semantics*: Search and Go act on the text in the urlbar, while
the rest of the buttons act on the page that is being displayed. When you use
Search or Go, the urlbar has content independant from the displayed page.

IMO, small, round icon buttons (no text) inside the url-toolbar would also
*look* better, because there wouldn't be so many very huge buttons.

Comment 9

[hangas]

*** Bug 51985 has been marked as a duplicate of this bug. ***

Comment 10

[gary_Cope]

bug 51985 doesnt look like a dupe of this bug to me. That bug is to do with
default appearance when address field has focus, not the general look and feel
of the button.

What concerned me when I filed this bug is that they look fugly in classic
theme, the buttons do not even appear to be aligned. They really need some
design love.

For the record I do not feel that the height of these buttons should be tied to
the height of the address field..that just seems like bad ui design to me. I am
sure there are ways of acheiving the equivalent heights in mozilla default skins
AND still giving theme designers some flexibility, however that is not the
subject of this bug.

Comment 11

[Joe Hewitt (gone)]

The fix for this bug is lumped in with the patch in bug 57429.  I apologize for
the lack of separation, but it was easiest for me to fix all my classic bugs in
one fell swoop.

What the fix does, specifically, is to clean up the alignment inside and outside
of these two buttons, and to prevent jumpiness on hover/active.  It doesn't
change them in any of the other ways suggested in this bug, because they look
the way marketing/UE wants them to look (last time I checked).  

Comment 12

[Joe Hewitt (gone)]

The debate here seems to be larger than just polish.  Moving to UI:DF to nail
down a better UI spec for this part of Navigator.

Comment 13

[Asa Dotzler [:asa]]

updating to new owner. sorry for the spam.

Comment 14

[Aaron Kaluszka]

Go button is still ugly.. this should be simple to fix, just change the
size/orientation.

Comment 15

[John Dobbins]

The Go Button is smaller than the Search button, and "Go" isn't Bold in Windows
and Linux.

Add the following lines to win's navigator.css to make the go button match the
search button.

#go-button
  {
    margin-right          : 5px !important;
    min-height            : 24px !important; 
    font-weight           : bold;
  }

Comment 16

[R.K.Aa.]

*** Bug 97915 has been marked as a duplicate of this bug. ***

Comment 17

[Gervase Markham [:gerv]]

Go is now bold, but the button is still really boring (a square). What would be
good is if Search matched Print and friends. But I bet there's a separate bug on
that.

Gerv

Comment 18

[Matthew T (active 1999-2002)]

While bug 49543 is not fixed, the Go and Search buttons should look like normal
pushbuttons, as shown in
<http://www2.holymac.com:7224/~holymac/news/images/toast/help_big.jpg> and
<http://www.augfrance.com/Microcam06/macx/images/osxhelp1.gif>.

Once bug 49543 is fixed, the Search button should look like other buttons on the
Toolbar, while the Go button should take the whole height of the Address Bar and
have no extra border.

--> Themes.

Comment 19

[Aaron Lawrence]

Attachment: Go and Search buttons as normal toolbar buttons

Just for interest, I hacked around and made the go and search buttons like
normal toolbar buttons (for the classic skin). I think it looks much better,
and they are still right beside the address field so they still look related.
Surprised to find this needed changes to the XUL as well. But this was my first
attempt at hacking Moz so could be completely wrong :)

Comment 20

[benc]

"ugly" was too vague.
I'm updating initally from Mac, but will look at other plats soon.
I've tried to read all the previous comments, and based on the ideas mentioned,
it seems like there are several problems:

1- go is default blue/bolded background - (looks okay in modern, but weird in
classic)
2- both go + search have height inconsistent w/ print and
[back/forward/reload/stop] (the three groups appear to be inconsistent when you
eyeball them).
3- icon +/- text : the other buttons use icon over text.

Comment 21

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 22

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 23

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 24

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 25

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 26

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 27

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420