You need to
before you can comment on or make changes to this bug.
In Safari, <INPUT> and anchor (<A>) elements within a block that has opacity applied to it will not receive the treatment (blue border, by default) indicating that the user has put focus on that element (e.g. by tabbing). A workaround is provided to use the :focus pseudoclass on <INPUT> and anchor elements within the wrapping semi-opaque element to manually apply a style indicating the user has focused on the element.
Reported on 26 October 2006.
Test page: http://www.mularien.com/browser_bugs/safari_link_opacity_bug.html
Tested on locally-built debug build of WebKit r18401 with Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8N1037).
Created an attachment (id=11984) [details]
Seems like an incremental repaint issue: note how forcing a repaint (e.g. by switching to a different tab and back) makes the focus ring appear where expected.
I also think this might be a bug in Core Graphics in Tiger.
Created an attachment (id=17174) [details]
reduced test case
First input is opacity:.9 and second is opacity:1.
I came across this same bug on my own, except I had the opacity set directly on the input itself (something the newer Webkit allows). Any opacity less than 1 will cause the focus glow to not draw.
I tested on a nightly download from 11/10/2007, build WebKit r27663 (on Tiger).
I cannot reproduce the reported issue in WebKit 39524 on Mac OS X 10.5.6.
(In reply to comment #6)
> I cannot reproduce the reported issue in WebKit 39524 on Mac OS X 10.5.6.
The bisect-builds script reports:
Fails: r28505 Works: r28565
Resolving as fixed.
Broken in Safari 3.0. Fixed in Safari 3.1 and later.
(In reply to comment #7)
> The bisect-builds script reports:
> Fails: r28505 Works: r28565
Probably fixed in <http://trac.webkit.org/changeset/28523> then.