Test case attached. Clicking on the left div does not dispatch the keydown event because the invisible <a> element does not receive focus. Adding a border to the <a> element (div in the right) will make it to receive focus, hence it will dispatch keydown event.
Created attachment 13512 [details] Testcase for both visible and invisible <a> element
WebKit behavior is different from Firefox, but seems more sensible to me - why focus an invisible element? Could you please describe why such technique is necessary?
See also: bug 10614.
As far as I can tell, the test case works as of Mac Safari version 5.0.2 (6533.18.5) and matches the behavior observed in Mac Firefox 3.6.8. Marking this as Resolved Fixed. If this is not the case, then please re-open this bug.
(In reply to comment #2) > WebKit behavior is different from Firefox, but seems more sensible to me - why focus an invisible element? Notice, the test case defines the <a> to be "visible" if it has a red border and "invisible" if it does not have a red border. This terminology differs from the terminology used in the HTML5 spec, which talks about elements "being rendered" <http://www.w3.org/TR/html5/rendering.html#being-rendered> or not. By the definition of "being rendered", the <a> is "being rendered" (since it doesn't specify "display: none" or "visibility: collapse" or any other styling that would exclude its rendering). Note, the <a> in the "invisible" case does not have an visible styling. For completeness, section 7.4.2 of the HTML5 spec <http://www.w3.org/TR/html5/editing.html#focus-management>, defines a focusable element.
(In reply to comment #5) > (In reply to comment #2) > > WebKit behavior is different from Firefox, but seems more sensible to me - why focus an invisible element? > > ... Note, the <a> in the "invisible" case does not have an visible styling. I meant to say: Note, the <a> in the "invisible" case does not have any visible traits or markings.