Closed Bug 245806 Opened 20 years ago Closed 19 years ago

"close tab" and "close find toolbar" button does not have a border creating button behaviour

Categories

(Toolkit :: Find Toolbar, defect, P4)

Product:
Toolkit
Component:
Find Toolbar
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.7.5

People

(Reporter: Peter6, Assigned: shorlander)

References

Details

Attachments

(4 files)

close-tab buttonstrip
1.20 KB, image/png
Details
png image showing current and desired button style and behavior
9.26 KB, image/png
Details
New Close-Tabs icon
3.29 KB, image/png
Details
patch for close tab area
1.78 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040607 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040607 Firefox/0.8.0+

the border is missing, in the new theme

Reproducible: Always
Steps to Reproduce:
1.Open Firefox
2.mouseover the close tab(s) button
3.there is no border showing

Actual Results:  
nothing

Expected Results:  
show an outset border

because of the marginal difference in luminocity between the 2 states of the
"close tab" image it's impossible to see if the mouse is on it or not.
Tested on crt and tft.
The biggest problem is, that the clickable area of the button doesn't stretch to
the screen border, so you must be much more careful when pointing at the button.
Also confirmed on Windows XP.  This bug is probably not OS specific.

Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7) 
Gecko/20040607 Firefox/0.8.0+

I see it on Linux but it seems more like desired operation than a "bug" to me.

OS -> All
OS: Windows 2000 → All
Bottom line is that it's a button. EVERY other button exhibits the highlight
behavior. It's really a consistency issue.
I agree that this is a bug. It has rendered the close button nearly useless for
me. It's impossible to hit the close button without looking now. 

I normally use Firefox maximized (and so do most people I've seen); I used to be
able to whip the mouse to the border of the screen, and hit the button. Now that
the button takes up a quarter of the area, and doesn't touch the side, I need to
aim carefully to use it. 

For reasons of speed, the single close button on the right-hand-side is a major
advantage of Firefox's tabbing interface over that of Galeon or Safari. Let's
not waste it! If we're gonna have small close buttons, we might as well put them
on every tab, and claim "it's more intuitive".

I propose that the summary field be changed to something that incorporates "too
small".
That should keep out dupes coming from people like myself.
I expected it to be fixed in FF0.9rc so I didn't ?0.9 it.
I know it's trivial, but given the other comments ....
move it on to 1.0beta if needed (can't choose that).
Flags: blocking0.9?
Confirmed

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040608
Firefox/0.8.0+
Moving blocking0.9? to blocking1.0?
Blocks bug 244691.
Blocks: 244691
Flags: blocking0.9? → blocking1.0?
There are really two issues reported here:
(a) the button should fill the space to make it easier to hit quickly
(b) the button should behave like all other toolbar buttons in the chrome and
highlight on mouse over
Assignee: firefox → webmail
Flags: blocking1.0? → blocking1.0+
It actually does highlight, just not by very much.
Priority: -- → P4
Target Milestone: --- → Firefox1.0
It seems to highlight fine in Arvid Qute theme though.  Is this just a minor css
problem in the theme?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Try adding the following lines to your userChrome.css as a workaround:

#content .tabs-closebutton {
  margin: 0 !important;
  border: 1px solid transparent !important;
  padding: 3px !important;
}
#content .tabs-closebutton:hover {
  border-color: ThreeDHighlight ThreeDShadow ThreeDShadow ThreeDHighlight
!important;
}
#content .tabs-closebutton:hover:active {
  border-color: ThreeDShadow ThreeDHighlight ThreeDHighlight ThreeDShadow
!important;
  padding: 4px 2px 2px 4px !important;
}
The same icon is also used as "close sidebar" button and it inherits the problem
as well.

(In reply to comment #9)
> There are really two issues reported here:
> (a) the button should fill the space to make it easier to hit quickly

This is the deal breaker. It should get the same mouse-over state as the other
buttons, meaning a border should appear around the image, making the full
container of the image become clickable. 

> (b) the button should behave like all other toolbar buttons in the chrome and
> highlight on mouse over

As Ben said, the button already does have a graphical highlight state, it's just
that it's not behaving like a standard toolbar button with a mouse-over border.
Attached image close-tab buttonstrip — 
additional comment, the button is a visable 14x14 px (1px tranparent around
it), but all small icons are 16x16 now.I added the strip for the button for
comment 12
Changed summary to
"close tab" and + "close find toolbar" + button does not have a border creating
button behaviour.
All coments apply for the new AVIARY "find toolbar" too
Summary: "close tab" button does not have a border creating button behaviour → "close tab" and "close find toolbar" button does not have a border creating button behaviour
-> Find Toolbar component.
Component: General → Find Toolbar / FastFind
It would be nice if, on Windows XP, these buttons looked the same as my themed
close window button in the window caption.
These buttons are too small. There is a bug to fix that in the tab toolbar, and
it should be fixed in the find bar as well. This should be tied in to the "large
icons" / "small icons" toggle in the regular toolbar menu. Some people like the
buttons larger.
If I'm not misunderstanding this bug, it's requesting two things. The first is
that the button have a mouse-over state like the other toolbar buttons. On
windows XP this means the raised button style demonstrated in this image. The
second request is that the mouse-over button icon levels be dropped a bit more
so that it's higher contrast and stronger saturation. 

This image shows, on the left, the current button and how it changes on
mouseover. The image shows, on the right, the desired behavior with button
state and icon adjustment.
Asa,
actually 3 !

1. Use 16x16 px images like used for all other small ICONs or favicons
(except in the find toolbar- but that's another thing).
2. increase the contrast of iconstate. Given that this is valid for the whole
theme this may be an unrealistic request (for short term anyway).
3. mouse-over state like the other toolbar buttons.

Peter, the icon colored image area does not need to be 16x16. It is being used
on special toolbars, is not configurable like other buttons, and to expand it to
the full 16 px and then put the winXP border on the button would probably
require adding more pixels to the height of the tab strip/toolbar. There are
plenty of UI elements that aren't 16x16 (take twisties, radio buttons, and
checkboxes, for example). As long as the entire highlighted button is clickable,
the actual area of color coverage by the icon itself isn't critical. Take folder
icons, for example, which don't cover the entire area of 16x16. Also, the fact
that it's a near solid colored square gives it the visual weight that's equal to
or greater than all of the other icons at 16x16.

Also, I've now closely analyzed the normal and hover state images and don't
think that it's out of scale with the rest of the 16x16 icons. I think the
actual difference is that the icon is designed differently than the others --
it's actually attempting to create it's own beveled depth within the icon (like
the IE "Go" button differs from the other IE icons). If we get a proper
mouseover button border, I think that the hover icon could probably remain the same.

So after more consideration, I think this bug really only needs to track one
issue, making the close button have a normal mouseover button border like other
toolbar buttons.
It is all trivial Asa ;-)
Do the normal behaviour.
Somewhere post-1.0 we may have the discussion again but I'm sure you agree the
other 2 issues are way to trivial to waist much time on.
Fix the behaviour and close this bug please ;-)
(In reply to comment #22)
> Peter, the icon colored image area does not need to be 16x16. It is being used
> on special toolbars, is not configurable like other buttons, and to expand it to
> the full 16 px and then put the winXP border on the button would probably
> require adding more pixels to the height of the tab strip/toolbar. There are
> plenty of UI elements that aren't 16x16 (take twisties, radio buttons, and
> checkboxes, for example). As long as the entire highlighted button is clickable,
> the actual area of color coverage by the icon itself isn't critical. Take folder
> icons, for example, which don't cover the entire area of 16x16. Also, the fact
> that it's a near solid colored square gives it the visual weight that's equal to
> or greater than all of the other icons at 16x16.
> 
> Also, I've now closely analyzed the normal and hover state images and don't
> think that it's out of scale with the rest of the 16x16 icons. I think the
> actual difference is that the icon is designed differently than the others --
> it's actually attempting to create it's own beveled depth within the icon (like
> the IE "Go" button differs from the other IE icons). If we get a proper
> mouseover button border, I think that the hover icon could probably remain the
same.
> 
> So after more consideration, I think this bug really only needs to track one
> issue, making the close button have a normal mouseover button border like other
> toolbar buttons.



Perhaps this button should be completely redone. Should this be opened as a new
bug? Is there an open bug for the default theme? Maybe it could go there.

This button is too small, and whatever it takes to make it work better is worth
it, especially to get it in early for a 1.0 fix.
I am taking over this bug from Kevin. I have updated CSS almost ready and new
image files for the icon that are more obvious between states.
Assignee: webmail → stephen
Status: NEW → ASSIGNED
Attached image New Close-Tabs icon — 
Well the whole point was to make the close "X" look like it's own button. Much
like the close button for the window itself. So having it floating in yet
another button is rather redundant. I made the hover state much more obvious,
it also has a pressed state. I think it is fairly obvious what is going on with
this button.
This patch will expand the click area of the close tab/sidebar/find-toolbar
buttons to make them easier to hit.
(In reply to comment #26)
> Created an attachment (id=154452)
> New Close-Tabs icon
> 
> Well the whole point was to make the close "X" look like it's own button. Much
> like the close button for the window itself. So having it floating in yet
> another button is rather redundant. I made the hover state much more obvious,
> it also has a pressed state. I think it is fairly obvious what is going on with
> this button.

Those three all look pretty close to the same to me. I imagine on a cheaper
monitor or smaller resolution, they would appear almost identical. They also
need to be quite a bit bigger.
Flags: blocking-aviary1.0PR?
All buttons have a marginal difference between the different icons states so I
suppose that's the choosen style we have to live with.
On a CRT screen it is visable on a TFT barely.
As long as the borders are according comment 12 it's ok with me.
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-
(In reply to comment #11)
> It seems to highlight fine in Arvid Qute theme though.  Is this just a minor css
> problem in the theme?
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9


Here is the bug for the theme fixes:
http://bugzilla.mozilla.org/show_bug.cgi?id=253738

The current stopbutton is really a lot better, thanks
if you click and hold down on the button now, and then move your mouse slowly
downward, the button flickers, so visually, this isn't perfect yet. 
Functionally, it is a lot better now; at least you can click all the way to the
right now.  It seems to me as if the clickable button area still needs a little
more height above the button though.  Also, the button still does not have the
raised gray border around it where the clickable area starts, unlike all other
buttons.
Also, if you drag the mouse pointer up the complete right side until the first
pixel is met that activates the button change, and then click and release there,
it doesn't close the tab.  So no only are there spots outside the button where
clicking WORKS, but spots that should work that DON'T.
Agreeing with #31-33. 

It is a step in the right direction, with a little more work to be done.

Fix the errors in 32 and 33, and make it just a tad bigger, and I guess I'd be
happy enough as well. Thanks.
p4 priority - not a blocker. if a fully reviewed patch materializes, please
nominate for aviary approval.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
The irregular clicking behaviour (comments 32, 33) should be corrected now, due
to one of the other theme bugs or checkins.
The buttons are still awfully small and hard to distinguish. Not to mention the
location on the left of the find "bar". Why not be consistent with the OS's
button size?
The button size will not be changing.
Is this one fixed or not? Should a new bug be filed? 
(In reply to comment #39)
> Is this one fixed or not? Should a new bug be filed? 

Yes this bug has been fixed for quite a while. I guess it can be closed.
(In reply to comment #40)
> (In reply to comment #39)
> > Is this one fixed or not? Should a new bug be filed? 
> 
> Yes this bug has been fixed for quite a while. I guess it can be closed.
Well, not really fixed.
The button doesn't have a border, at least not in Windoze Steven
It just changes color on mouseover/down.
This in contrast to any other button which is raised at mouseover and depressed
at mousedown

(In reply to comment #41)
> (In reply to comment #40)
> > (In reply to comment #39)
> > > Is this one fixed or not? Should a new bug be filed? 
> > 
> > Yes this bug has been fixed for quite a while. I guess it can be closed.
> Well, not really fixed.
> The button doesn't have a border, at least not in Windoze Steven
> It just changes color on mouseover/down.
> This in contrast to any other button which is raised at mouseover and depressed
> at mousedown
> 

No it doesn't have a border. That would be a won't fix. I did increase the active area and make it more 
obvious.


ok, I'll resolve the bug with fixed.
It's something in the middle ;-)
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: