Lose focus when .focus() is called while the element already has the focus
Description
The paper-input element appears to lose its focus when .focus() is called while it already has the focus.
Expected outcome
Calling .focus() on paper-input when it's already in focus should keep the focus in the iron-input component.
Actual outcome
While paper-input appears to still have the focus (.focused === true), the iron-input inside is not (therefore, editing is not possible) and the appearance indicates out of focus.
Steps to reproduce
- Put a
paper-inputelement in the page. - Open the page in a web browser.
- Use some delaying mechanism (
window.setTimeoutorwindow.setInterval) to queue a.focus()call after some time. - Focus on the
paper-inputelement before the.focus()call triggers. - Wait for the
.focus()call to trigger. Thepaper-inputelement will appear to have lost its focus.
Live demo
This issue can be demonstrated with any live page with a paper-input element (for example, this page on WebComponents) by running the following code in console:
window.setInterval(() => {
document.querySelector('paper-input').focus();
console.log(document.querySelector('paper-input').focused);
}, 5000);
After the code above was run, whenever the first paper-input element on the page gets the focus, it will be gone during the next cycle in no more than 5 seconds. Console log will show that the .focused property of the paper-input is still true.
Browsers Affected
- [X] Chrome
- [X] Firefox
- [ ] Safari 9 (not tested)
- [ ] Safari 8 (not tested)
- [ ] Safari 7 (not tested)
- [X] Edge
- [ ] IE 11 (not tested due to not supporting ES6 features in the testing code)
- [ ] IE 10 (not tested)
While checking .focused before calling .focus() can be a workaround for this issue in most cases, this workaround will not prevent cases in other libraries (which should not expect .focus() to have such a behavior). For example, when using iron-dropdown's focusTarget property to link to a paper-input (I suppose .focus() is called in iron-dropdown's code).