A disabled paper-checkbox may be focused
Description
If focus() is called on a disabled paper-checkbox, it actually becomes focused (i.e. it is the activeElement). This does not match the behavior of, say, a <button> which cannot be focused when disabled.
This can trip up a user that has a paper-checkbox in a <dialog> for which showModal is called. The dialog automatically focuses the first focusable element. If that's a disabled paper-checkbox, the result will be unexpected.
Live Demo
http://jsbin.com/kobemoq/edit?html,output
Browsers Affected
- [x] All
It looks like the offending line is in iron-control-state and that this will affect al implementers of iron-control-state.
That code could be changed to removeAttribute('tabindex') if there is no more explicit way to remove focusability.
removeAttribute('tabindex')
this would help for custom elements, but not for <button> or <input> (which are focusable without a tabindex).
in the case of default focusable elements like <input>, there's really no good way to ignore it from being focused when a <dialog> is shown modally, as they're either a form control element or have the "tab index customization flag" if you use tabindex="-1" and therefore qualify as a control in https://html.spec.whatwg.org/#dialog-focusing-steps
just FYI.
strawman:
this.removeAttribute('tabindex');
if (this.tabIndex >= 0)
this.tabIndex = -1; // TODO(somebody): this doesn't work well in <dialog>#showModal().
@danbeam native elements don't use IronControlState, so I don't know how we'd ever fix that. If the behaviour of a native <input> inside a native <dialog> is broken, that sounds like a spec but, or a browser bug, but absolutely not something we can fix... :(
don't we do <input is="..."> in polymer 1? does that not use IronControlState?
Nope, iron-input doesn't use that, because the native input already has all the native focus behaviour: https://github.com/PolymerElements/iron-input/blob/master/iron-input.html