11680 - GFX checkboxes lack tracking feedback

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P3)

Description

[Simon Fraser [no longer active]]

GFX checkboxes are not showing any tracking feedback. Look at the Find dialog for
examples.

By tracking feedback, I mean the change in appearance when the mouse is down, and
you move in and out of the control.

Comment 1

[Mike Pinkerton (not reading bugmail)]

this works for gfx checkboxes in web pages (like the bugzilla query page). I
think you just need to specify a :hover or :active, as demonstrated in ua.css for
the checkboxes in our dialogs/chrome.

Comment 2

[Simon Fraser [no longer active]]

Does it matter that those are in HTML, whereas the ones in the find dialog are in
an HTML namespace in XUL? FYI, the checkboxes in the preferences lack tracking
feedback too.

Comment 3

[Mike Pinkerton (not reading bugmail)]

no, the ones in xul use additional css files, i think, that probably don't
specify the correct psuedo-styles. i don't think it has to do with the fact that
they're used in xml.

Comment 4

[german]

I'll look into this but not before m10.
+ G

Comment 5

[german]

this seems to work properly in the current build.

Comment 6

[Simon Fraser [no longer active]]

I see no tracking feedback in either the 'Open location' dialog, or the
preferences.

Comment 7

[german]

I shall look into it. (Past Dogfood)

Comment 8

[Paul MacQuiddy]

giving me rest of phillips open qa contact bugs, sorry for spam

Comment 9

[german]

Tracking feedback works in todays build, but does not use CSS outlines as
specified in UI spec. Instead it replaces the current inset border.

moving to m15. Peter (Toolkit/Widgets Team), do you know whether CSS outlines
work properly now? If so we should implement a 1px solid black outline mouseover
feedback for checkboxes. Also the current 2px inset border of the widget should
be changed to 1px then.

Comment 10

[Mike Pinkerton (not reading bugmail)]

if anything, this would be a gecko bug. checkboxes are owned by them.

Comment 11

[Peter Trudelle]

changing component to HTML Form Controls, clearing target milestone,
reassigning.

Comment 12

[karnaze (gone)]

Reassigning to Rod.

Comment 13

[rods (gone)]

I just got this bug from Kevin, is this still a bug and if so, what exactly is
wrong with it?

Comment 14

[Simon Fraser [no longer active]]

I think the basic problem that this describes was a CSS thing, and has been
fixed. However, our control mouse tracking is still messed up. Open the 'Find on
this page' dialog for an example. Click on the 'Case senstive checkbox', and hold
the mouse down, moving in and out of the the control. Note the following errors
in control tracking:

1. The state of the button is changed on mouse down (i.e. the check mark appears
when you first click), instead of on mouse up like the OS checkboxes. This is
wrong. The state of the button should only change if the user REALEASES the mouse
button while the cursor is IN THE CONTROL. This allows the user to mouse away and
release to change their mind.

2. Mousing down in a checkbox leaves a nasty 2-pixel dotted border behind, which
looks like shit.

3. If you click and hold on one checkbox, then drag the mouse around, mousing
over another checkbox draws a hover outline around that second checkbox. This is
also wrong; ONLY the control that was first clicked on should show any changes in
state while dragging around; other controls should be 'dead' until the user
releases the button. Again, this is how native widgets behave.

Comment 15

[Mike Pinkerton (not reading bugmail)]

we should file 3 separate bugs for this, per simon's comments, and close this one
out.

Comment 16

[rods (gone)]

Item #1 - I have a fix in my tree for having it check it on the mouse up, I also
make sure that if you mouse down in one control, hold the mouse down and then
mouse up in another control nobody gets checked.
Item #2 - This used to work fine, and is currently a part of the many bugs owned
by the saari for focus.
Item #3 - This is the way the event state manager works today. It does track
the mouse down state as part of activating "hover". It is either a bug or an
enhancement for Joki, feel free to file a bug on him for this.

I will close this out when I check in the fix for item #1

Comment 17

[rods (gone)]

fixed

Comment 18

[Paul MacQuiddy]

qa to jrgm

Comment 19

[jerone]

verifried build 2001081308 os:mac8.6