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.
It seems that we should probably match the behaviors of other browsers but maybe Sam, Alexey, or Darin have a different opinion here.
Add Chris & James since this impacts the accessibility.
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
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.
@pxlcoder & @rniwa - Is this from chrome patch - HTMLFormControlElement::rendererIsFocusable() equivalent of void HTMLFormControlElement::didAttachRenderers()?
I'm pretty sure I've already fixed this.