Bug 122793
| Summary: | Make it possible to focus on 0-size form controls and anchors | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Ryosuke Niwa <rniwa> |
| Component: | Forms | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED CONFIGURATION CHANGED | ||
| Severity: | Normal | CC: | ahmad.saleem792, akeerthi, ap, cfleizach, darin, jcraig, rniwa, sam, tkent |
| Priority: | P2 | Keywords: | BlinkMergeCandidate, WebExposed |
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Ryosuke Niwa
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
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
Add Chris & James since this impacts the accessibility.
chris fleizach
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
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
@pxlcoder & @rniwa - Is this from chrome patch - HTMLFormControlElement::rendererIsFocusable() equivalent of void HTMLFormControlElement::didAttachRenderers()?
Ryosuke Niwa
I'm pretty sure I've already fixed this.