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)
Core
Layout: Form Controls
Tracking
()
NEW
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
Comment 1•14 years ago
|
||
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
Comment 2•14 years ago
|
||
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?
Comment 3•14 years ago
|
||
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?
Comment 4•14 years ago
|
||
I have no idea. What would be cleanest and fastest?
Comment 5•14 years ago
|
||
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
Comment 6•14 years ago
|
||
> 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.
Comment 7•14 years ago
|
||
(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.
Comment 8•14 years ago
|
||
> 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....
Comment 9•14 years ago
|
||
(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.
Comment 12•11 years ago
|
||
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.
Comment 13•11 years ago
|
||
> I haven't read the specs
The specs leave the rendering of form controls completely undefined.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•