Closed Bug 11680 Opened 21 years ago Closed 21 years ago
GFX checkboxes lack tracking feedback
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.
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.
I see no tracking feedback in either the 'Open location' dialog, or the preferences.
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.
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 ago → 21 years ago
Resolution: --- → 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.