Closed Bug 341317 Opened 18 years ago Closed 18 years ago

[regression] All form controls styled with the border property get focus outlines when one is focused


(Core Graveyard :: GFX: Mac, defect)

1.8 Branch
Not set


(Not tracked)



(Reporter: phiw2, Assigned: mark)



(Keywords: fixed1.8.1, regression, testcase)


(2 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.9a1) Gecko/20060613 Camino/1.2+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060525 Minefield/3.0a1

A form control that has the border property applied has focus. Subsequent form controls equally styled with the border property then also show a dotted black focus ring.

I'll attach a test case next.
If seen this happen on a variety of widgets (input[type=submit], textarea, input[type=text],..) in complex forms

Regression range:
Works correctly:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060524 Minefield/3.0a1

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060525 Minefield/3.0a1 -- fails

Reproducible: Always

Steps to Reproduce:
1. load upcoming testcase
2. click on first select widget
3. watch second select widget get a focus ring

Expected Results:  
No focus ring on subsequent widgets
Attached file test case
Product: Firefox → Core
Version: unspecified → Trunk
Component: General → Layout: Form Controls
QA Contact: general → layout.form-controls
Confirmed with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060608 Minefield/3.0a1.
Keywords: regression, testcase
Summary: [regression] Form controls styled with the border property leak outline focus ring when focussed → [regression] All form controls styled with the border property get focus outlines when one is focused
Ever confirmed: true
I've now been able to reproduce the problem with a Camino trunk as well, to a certain extend. At least I think it is related to this bug. The symptoms are quite similar.

I was doing some translation on Google Translate, and Google had misspelled a translated word, or rather, Google uses En-US spelling, while my OS spell-checker (as used by Camino) us set to British English).
With a misspelled word in the textarea for translated text, the textarea where one inputs text to be translated displays with a dotted border. If the translated text has only correct spelling, then the other textarea displays correctly.

(the spellchecking stuff was partly hooked up to Camino in bug 151040 with the 20060617 Camino trunk builds)
See also philippe's bug 341980 comment 8. 

Checkins from comment 0: 

Interestingly, the range mentioned in comment 0 here has bug 338374 landing, which might either be the cause, or have just made some even older underlying bug suddenly appear.
One more thing I noticed - and this probably explains why the problem is not visible with the default styling of widgets in Firefox.

The border-width must be 1px (or 2px if  the -moz-border property is used - as this actually paints two 1px borders) for the problem to be visible.
*** Bug 341980 has been marked as a duplicate of this bug. ***
Someone's using the same rendering context to draw the borders as was used to draw the dotted focusy area, but nobody's ever calling SetLineStyle to restore the original line style or set it to solid.
Also occurs on 1.8 branch.
Component: Layout: Form Controls → GFX: Mac
Flags: blocking1.8.1?
Version: Trunk → 1.8 Branch
Assignee: nobody → mark
Attached patch Patch v1Splinter Review
We should have caught this comment the first time around...

// note: the line style must be saved in the nsGraphicState like font, color, etc...

I'm taking mLineStyle out of nsRenderingContextImpl because it seems that it's only ever used on the Mac, which is ironic, because it wasn't ever used for anything useful on the Mac.
Attachment #227481 - Flags: review?(joshmoz)
--> blocking beta2, josh, could we please get an expedient review so we can land this and bake it on trunk? we'd take it for beta 1 if it was ready in time ...
Flags: blocking1.8.1? → blocking1.8.1+
Target Milestone: --- → mozilla1.8.1alpha2
(In reply to comment #9)
> Created an attachment (id=227481) [edit]
> Patch v1

Nice. With this patch applied to Camino-trunk and Minefield, all my testcases now work correctly.
Attachment #227481 - Flags: review?(joshmoz) → review+
Checked in on trunk.
Closed: 18 years ago
Resolution: --- → FIXED
Attachment #227481 - Flags: approval1.8.1?
(oops, I think this was meant to be targetted at beta2, not alpha2)
Target Milestone: mozilla1.8.1alpha2 → mozilla1.8.1beta2
Comment on attachment 227481 [details] [diff] [review]
Patch v1

You are cleared to land, a=drivers
Attachment #227481 - Flags: approval1.8.1? → approval1.8.1+
Field in sight.
Keywords: fixed1.8.1
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.