Skip to content
This repository has been archived by the owner on Dec 19, 2024. It is now read-only.

A disabled paper-checkbox may be focused #160

Open
1 task done
sorvell opened this issue Nov 4, 2016 · 5 comments
Open
1 task done

A disabled paper-checkbox may be focused #160

sorvell opened this issue Nov 4, 2016 · 5 comments

Comments

@sorvell
Copy link
Contributor

sorvell commented Nov 4, 2016

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

  • All
@sorvell
Copy link
Contributor Author

sorvell commented Nov 4, 2016

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.

@danbeam
Copy link
Contributor

danbeam commented Nov 4, 2016

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().

@notwaldorf
Copy link
Contributor

@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... :(

@danbeam
Copy link
Contributor

danbeam commented Nov 8, 2016

don't we do <input is="..."> in polymer 1? does that not use IronControlState?

@notwaldorf
Copy link
Contributor

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants