You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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-input element in the page.
Open the page in a web browser.
Use some delaying mechanism (window.setTimeout or window.setInterval) to queue a .focus() call after some time.
Focus on the paper-input element before the .focus() call triggers.
Wait for the .focus() call to trigger. The paper-input element 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:
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
Chrome
Firefox
Safari 9 (not tested)
Safari 8 (not tested)
Safari 7 (not tested)
Edge
IE 11 (not tested due to not supporting ES6 features in the testing code)
IE 10 (not tested)
The text was updated successfully, but these errors were encountered:
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).
Description
The
paper-input
element appears to lose its focus when.focus()
is called while it already has the focus.Expected outcome
Calling
.focus()
onpaper-input
when it's already in focus should keep the focus in theiron-input
component.Actual outcome
While
paper-input
appears to still have the focus (.focused === true
), theiron-input
inside is not (therefore, editing is not possible) and the appearance indicates out of focus.Steps to reproduce
paper-input
element in the page.window.setTimeout
orwindow.setInterval
) to queue a.focus()
call after some time.paper-input
element before the.focus()
call triggers..focus()
call to trigger. Thepaper-input
element 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: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 thepaper-input
is stilltrue
.Browsers Affected
The text was updated successfully, but these errors were encountered: