Closed Bug 11680 Opened 21 years ago Closed 21 years ago

GFX checkboxes lack tracking feedback

Categories

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

All
Mac System 8.5
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: sfraser_bugs, Assigned: rods)

Details

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.
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.
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.
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.
Status: NEW → ASSIGNED
I'll look into this but not before m10.
+ G
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
this seems to work properly in the current build.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I see no tracking feedback in either the 'Open location' dialog, or the
preferences.
Status: REOPENED → ASSIGNED
Target Milestone: M13
I shall look into it. (Past Dogfood)
giving me rest of phillips open qa contact bugs, sorry for spam
Assignee: german → trudelle
Status: ASSIGNED → NEW
Target Milestone: M13 → M15
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.
if anything, this would be a gecko bug. checkboxes are owned by them.
Assignee: trudelle → karnaze
Component: XP Toolkit/Widgets → HTML Form Controls
Target Milestone: M15
changing component to HTML Form Controls, clearing target milestone,
reassigning.
Assignee: karnaze → rods
Reassigning to Rod.
I just got this bug from Kevin, is this still a bug and if so, what exactly is
wrong with it?
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.
we should file 3 separate bugs for this, per simon's comments, and close this one
out.
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
Status: NEW → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
fixed
qa to jrgm
QA Contact: paulmac → jrgm
verifried build 2001081308 os:mac8.6
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.