Open Bug 618156 Opened 14 years ago Updated 2 years ago

Setting CSS border style on input field loses blue glow for when field focused on Mac

Categories

(Core :: Layout: Form Controls, defect)

defect

Tracking

()

People

(Reporter: spoon.reloaded, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 On Firefox and SeaMonkey on Mac OS X, by default a focused text field (or any other focused form element) is outlined in a blue "glow" surrounding the border of the field. However, if you set ANY kind of CSS border style on it, the glow no longer shows. Reproducible: Always Steps to Reproduce: 1. Display a page with this: <input /> It has a blue glow outline when you click in it (i.e. focus the field) 2. Display pages with the following: <input style="border-color:#888888;" /> <input style="border-style:solid;" /> <input style="border-width:1px;" /> Actual Results: The latter three do not show a blue glow when you click in them. Expected Results: All of them should show a blue glow when you click in them. I don't understand why setting something simple like the width of the border, is relevant to the behavior of the blue glow at all. Is it possible to have a blue glow and a customized border at the same time, perhaps through additional CSS attributes? In Safari and Chrome on Mac, they show the blue glow even when you set a border style
The glow isn't drawn by us; it's drawn by the native theming engine, as far as I can see. When you set a non-default border, we can no longer use the native theming engine to draw the control, since it doesn't support that, so we have to fall back on drawing it ourselves. I suppose we could try to fake the focus glow somehow... Josh, Markus, any idea how to go about doing that?
Component: General → Layout: Form Controls
QA Contact: general → layout.form-controls
In particular, we just set isFocused to true on the HIThemeFrameDrawInfo that we pass to HIThemeDrawFrame, when we're painting the text input. But for the case of textareas, we actually have a separate codepath to use HIThemeDrawFocusRect. Could we still use that for non-native-themed text controls?
Sure. We can also use NSSetFocusRingStyle(NSFocusRingOnly) as we're doing in DrawFocusRing for search fields to draw focus around arbitrary shapes. Then the focus ring could even follow rounded corners. The biggest question for me is what the API to nsITheme should look like. For example, should we pass in a rect and an array of border radii, or should nsCSSRendering draw the background shape of the textfield into a new surface and pass that surface to nsITheme?
I have no idea. What would be cleanest and fastest?
If we do that, :-moz-appearance: none would keep the system focus ring? Wouldn't that be weird?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → Trunk
> If we do that, :-moz-appearance: none would keep the system focus ring? That's what the webkit-based browsers do, yes. > Wouldn't that be weird? Good question! Right now we don't draw a focus indicator at all there, as far as I can tell.
(In reply to comment #6) > > If we do that, :-moz-appearance: none would keep the system focus ring? > > That's what the webkit-based browsers do, yes. But there you can still opt out with outline: none. (In reply to comment #4) > I have no idea. What would be cleanest and fastest? I don't know yet, I'll have to do some reading around nsCSSRendering.cpp.
> But there you can still opt out with outline: none. Hmm. So do they have a magic outline value which means "platform default" or something? We could do that....
(In reply to comment #7) > (In reply to comment #6) > > > If we do that, :-moz-appearance: none would keep the system focus ring? > > > > That's what the webkit-based browsers do, yes. > > But there you can still opt out with outline: none. We agree that currently outline has nothing to do with the focus ring? I don't understand why, when the element is not using the system default, we should still keep a part of this system default. This doesn't seem right to me. Someone who want to not use the system default should implement a focus ring of its own. To me, it's not shocking to not have a focus ring: a lot of gtk themes do not have one and, IIRC, older Windows version don't have one. The fact that changing the border style make us not use the system default is another issue, IMO.
This issue is still present in FF28 - even adding a border-radius suppresses the default outline. It's possible but I'm disinclined to think that this is a bug in OSX because the same behavior is not observable in Safari, Chrome, or Opera - though maybe each of those browsers patches the bug somewhere along the line? I haven't read the specs but it seems like the correct behavior would be for editing border styles to not affect the outline styles, it would be better (and more consistent with other clients) to have the option to customize the borders of your inputs and buttons without also having to customize their outlines.
> I haven't read the specs The specs leave the rendering of form controls completely undefined.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.