WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED CONFIGURATION CHANGED
122793
Make it possible to focus on 0-size form controls and anchors
https://bugs.webkit.org/show_bug.cgi?id=122793
Summary
Make it possible to focus on 0-size form controls and anchors
Ryosuke Niwa
Reported
2013-10-14 17:40:59 PDT
Consider merging
https://chromium.googlesource.com/chromium/blink/+/53f8eba14b6362795bae47c02236ca93303264a6
We assumed form controls and anchor elements with 0-size were not focusable. It's inconsistent with other elements with tabIndex or contentEditable, and incompatible with IE11 and Firefox 23. We remove rendererIsFocusable override of HTMLFormControlElement, and remove renderer box check in HTMLAnchorElement::isKeyboardFocusable. As for crbug.com/285595, when we removed focus from an input/textarea element by 0-size, the element kept the selection. So FrameSelection::setFocusedNodeIfNeeded set focus on the element again when an editing command was invoked by a keyboard input. This issue is revolved by this CL because we don't remove focus by 0-size.
Attachments
Add attachment
proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1
2013-10-14 17:41:45 PDT
It seems that we should probably match the behaviors of other browsers but maybe Sam, Alexey, or Darin have a different opinion here.
Ryosuke Niwa
Comment 2
2013-10-14 17:42:34 PDT
Add Chris & James since this impacts the accessibility.
chris fleizach
Comment 3
2013-10-14 17:46:03 PDT
I wonder what the use case for this is. Generally VoiceOver will ignore 0 sized based elements every where because they're much more likely to be left their erroneously by developers rather than be real elements the user is meant to interact with
James Craig
Comment 4
2013-10-20 17:16:53 PDT
I expect it’s okay to merge this, unless there is an informative comment in the source stating the reason for the strange current behavior. Only thing that comes to mind would to check if this affects elements with size but no rendering (e.g. visibility:hidden;) or elements that are rendered outside a clipped region. I wouldn’t expect either to apply, but I’ve been surprised before.
Ahmad Saleem
Comment 5
2022-12-20 11:44:58 PST
@pxlcoder & @rniwa - Is this from chrome patch - HTMLFormControlElement::rendererIsFocusable() equivalent of void HTMLFormControlElement::didAttachRenderers()?
Ryosuke Niwa
Comment 6
2022-12-20 12:01:08 PST
I'm pretty sure I've already fixed this.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug