Open caoxiaoyi03 opened 5 years ago
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