Unexpected input event is fired when focus leaves the input element
Categories
(Core :: DOM: Events, defect, P3)
Tracking
()
People
(Reporter: doug.hs, Assigned: m_kato)
Details
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Steps to reproduce:
https://jsbin.com/xulahutumo/edit?output
- Open the JS Bin link above on Firefox for Android. It simulates a search field with autocomplete or instant search functionality (the combobox pattern).
- On the form field presented, type anything. When you do, the popup box will appear below the form. The count of input events displayed below will increase as you type.
- Now tap away from the form field to trigger a blur event. The popup box will close when you do that.
- See what happened? The event counter increased, but you didn't input anything on the form. You simply unfocused it. Why?
Actual results:
An 'input' event is being fired whenever focus leaves the input element. On a web application I'm building, this is responsible for making the popup element close and reopen shortly after, stuck in an unresponsive state. That is because I have an open() method call being made on every input event.
Expected results:
Unfocusing an input element should not trigger an input event. I believe this is a bug.
So far I have also tested Google Chrome on Android, and this issue is not reproducible with it.
The JS Bin link above doesn't work anymore.
This is the new URL: https://jsbin.com/xulahutumo
Ignore comment 1. The JS Bin link on the description still works.
I was able to reproduce the problem with Firefox Preview 3.2.0 retrieved from the Play Store.
Hi, I managed to reproduce the issue on Firefox Release 68.5.0, Firefox Beta 68.6b1, Firefox Nightly 68.5a1 (2020-01-20) and Firefox Preview Nightly 200213 (Build #20440605) GV: 74.0a1-20200210093912 with Google Pixel 3 XL (Android 10) and Samsung Galaxy S8+ (Android 8.0.0), with both links.
Note:
- Only when you do the first unfocus does input event been triggered and the count being updated.
- Video
Created ticket on github for Fenix: https://github.com/mozilla-mobile/fenix/issues/8375
|
||
Comment 6•4 years ago
|
||
Asking the GV team to triage this one.
|
||
Updated•4 years ago
|
|
||
Comment 7•4 years ago
|
||
athomas, what makes this P1?
masayuki, any ideas why blurring increments the counter?
|
||
Comment 8•4 years ago
|
||
Although the video is too small and really short (cannot zoom-in before its end), and I cannot see the composition string visual. I guess that inputting string is a composition string and moving focus causes committing string. For making it clearer, you should listen to composition end event and logs InputEvent.inputType of input event.
Makoto-san, could you take a look?
|
Assignee | |
Comment 9•4 years ago
|
||
Yes, but I don't understand why this is P1.
|
|
Assignee | |
Comment 10•4 years ago
|
||
This doesn't depends on GeckoView. When using GBoard, most characters are inserted as composition string. So when firing blur, we commit composition. In this situation, Gecko dispatches input event after firing compostionend event. This is same behavior as Firefox desktop.
Blink and WebKit don't dispatch input event after composition event. So this is a kind of compatibility issue.
Nakano-san, which is correct?
|
|
||
Comment 11•4 years ago
|
||
Thank you for the investigation, then this is dup of bug 1305387.
Well, under current draft specs, Blink and WebKit confirm to the specs. However, we know that the behavior does not make sense because web apps needs to listen compositionend separately because isComposing of input event immediately before compositionend needs to be true.
See https://github.com/w3c/uievents/issues/202
(we need to fix some points in our chrome code, if we change our behavior, and it makes current code more complicated.)
However, indeed, this can causes web-compat issues.
We should try to think a good way to change the our behavior anyway...
|
||
Updated•4 years ago
|
Description
•