Updates to inputmode/enterkeyhint don't take effect until the next time the text field is focused.
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox93 | --- | fixed |
People
(Reporter: rkjnsn, Assigned: m_kato)
References
Details
Attachments
(3 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:81.0) Gecko/20100101 Firefox/81.0
Firefox for Android
Steps to reproduce:
(I discovered this bug on Firefox Android, but I'm filing here since this is where the other enterkeyhint bugs are. Let me know if I should file on Github, instead.)
- Visit https://jsfiddle.net/06dopzac/4/show on Firefox Nightly on Android.
- Tap focus the text field.
- Type some text.
Actual results:
The symbol on the enter key doesn't change unless one unfocuses and refocuses the text field.
Expected results:
The symbol on the enter key should change from "enter" to "send" as soon any text has been entered into the text field.
Reporter | ||
Comment 1•4 years ago
|
||
The source code of the sample can be viewed at https://jsfiddle.net/06dopzac/4.
This issue also occurs when setting mozactionhint dynamically. The sample works as expected on Chrome.
I need this functionality for an in-progress web app.
Comment 2•4 years ago
|
||
Hello, Erik thank you for this report!
https://github.com/mozilla-mobile/fenix/issues/17046
Assignee | ||
Comment 3•4 years ago
|
||
We initialize this value when taking focus. So I think that we should call SetInputContext when changing this value.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Comment 4•4 years ago
|
||
(In reply to Makoto Kato [:m_kato] from comment #3)
We initialize this value when taking focus. So I think that we should call SetInputContext when changing this value.
It looks like the path to fix is simple enough. Can you suggest an assignee?
Assignee | ||
Comment 5•4 years ago
|
||
(In reply to Henri Sivonen (:hsivonen) (away from Bugzilla until 2021-01-11) from comment #4)
(In reply to Makoto Kato [:m_kato] from comment #3)
We initialize this value when taking focus. So I think that we should call SetInputContext when changing this value.
It looks like the path to fix is simple enough. Can you suggest an assignee?
I would like to ship this, so I handle this. But changing enterkeyhint
dynamically causes that keyboard layout is changed (It means that composing text is destroyed). So this is related to https://github.com/whatwg/html/issues/4876 and I have to check iOS's implementation.
Assignee | ||
Comment 6•4 years ago
|
||
Safari/iOS doesn't support dynamically updating of enterkeyhint. Until resolving https://github.com/whatwg/html/issues/4876, we won't handle this...
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 7•3 years ago
|
||
Assignee | ||
Comment 8•3 years ago
|
||
Blink and WebKit support dynamically change of inputmode
. When the focused
element's inputmode
value is changed, software keyboard layout will be
changed by new value.
Actually, Gecko references it when getting focus only now. So we should apply
dynamically change like other browsers.
Also, enterkeyhint
has same issue. Current WebKit is same behaviour as
Gecko, but Blink is same as inputmode
behaviour. So I would like to change
this like inputmode
.
Assignee | ||
Comment 9•3 years ago
|
||
When focus isn't changed and inputmode in focused element is changed to none,
we should dismiss software keyboard.
Also, this has same issue for changing from none to text to show software
keyboard.
When changing inputmode, icNotifyIMEContext is called then we should control
software keyboard open/close state too.
Depends on D122490
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 11•3 years ago
|
||
Depends on D122491
Comment 12•3 years ago
|
||
Comment 13•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/3519ff8b4fb4
https://hg.mozilla.org/mozilla-central/rev/7c447196c23c
https://hg.mozilla.org/mozilla-central/rev/133d10dbf4c7
Description
•