Closed Bug 341317 Opened 15 years ago Closed 15 years ago
[regression] All form controls styled with the border property get focus outlines when one is focused
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 Fails: 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
Product: Firefox → Core
Version: unspecified → Trunk
Confirmed with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060608 Minefield/3.0a1.
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: http://tinyurl.com/pywtq 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
Version: Trunk → 1.8 Branch
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)  > Patch v1 > Nice. With this patch applied to Camino-trunk and Minefield, all my testcases now work correctly.
Checked in on trunk.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
(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.
You need to log in before you can comment on or make changes to this bug.