Closed Bug 864120 Opened 8 years ago Closed 8 years ago
Use a display list item to create the focus ring for <input type=range> to avoid double focus rings when native theming handles the visual indication of focus
Having backed out bug 862693 (Stop the :-moz-focusring pseudo-class from matching if an element is themed and the theme will display a visual indication of focus for the element), we'll need to use the approach of creating the focus ring using a special display list item.
Gah, somehow failed to notice I'd forgotten to get review on this and land it.
Attachment #748614 - Flags: review?(roc)
This is a simplified version of what nsButtonFrameRenderer, without the messing around with stored nsStyleContexts.
Attachment #748614 - Flags: review?(roc) → review+
Comment on attachment 748614 [details] [diff] [review] patch [Approval Request Comment] Bug caused by (feature/regressing bug #): none - new feature User impact if declined: annoying double focus Testing completed (on m-c, etc.): landed on m-i before uplift Risk to taking this patch (and alternatives if risky): low String or IDL/UUID changes made by this patch: none
Attachment #748614 - Flags: approval-mozilla-aurora?
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
Attachment #748614 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Verified as fixed on the Firefox 23 RC and the 08/01 Aurora and Nightly, on Windows 7 64bit, Mac OSX 10.8.3 and Ubuntu 13.04 32bit. Where there is no other focus visual feedback, the focus ring is displayed. When the OS theme came with a visual indication of focus, the ring didn't get displayed anymore.
Summary: Use a display list item to create the focus ring for <input type=range> → Use a display list item to create the focus ring for <input type=range> to avoid double focus rings when native theming handles the visual indication of focus
You need to log in before you can comment on or make changes to this bug.