onfocus event is firing again when selection is changed first time
Reported by
lge-systemwebview@lge.com,
Jun 27 2017
|
|||||||||||
Issue descriptionTHIS TEMPLATE IS FOR FILING BUGS ON THE ANDROID SYSTEM WEBVIEW. GENERAL WEB BUGS SHOULD BE FILED USING A DIFFERENT TEMPLATE! Device name: LG G6, Samsung S6 Android version: 7.0 WebView version (from system settings -> Apps -> Android System WebView):58.0.3029.83 Application: Sample App Application version: URLs (if applicable): Steps to reproduce: (1) Install the APK (2) Cursor is in Subject->Click IME Next button (3) Observe focus event is fired twice Expected result: focus event behavior should be uniform Actual result: focus event is fired again. Whenever user clicks IME next to focus Webview editor, focus is coming to editor but cursor is not placed by WebView by default. To overcome that, we are placing the cursor manually by creating the collapsed range and adding to selection (See setCaretPositionForInsert function in the attached source code) during focus event. But when addRange is called, focus event is fired one more time. This second time focus event is effecting the internal logic.
,
Jun 28 2017
Is this a regression from behaviour a previous webview version?
,
Jun 29 2017
Thank you for providing more feedback. Adding requester "tobiasjs@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 10 2017
not sure why comment 3/4 are deleted, but it used to say "This behavior was observed in previous stable version also." The apk you attached doesn't run. Presumably it's a multi-dex apk and you only included the main apk. Also which focus event are you talking about exactly? JS event on a DOM node, or Java event on a View?
,
Jul 11 2017
It is my mistake.. Attached proper APK. 1. JS event on a DOM node
,
Jul 11 2017
Thank you for providing more feedback. Adding requester "boliu@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 17 2017
tobiasjs@ and boliu@ can you look at the proper apk in comment 7?
,
Jan 13 2018
Bo, is WebView's behavior actually wrong here? I tried the same page in Chrome but Chrome doesn't generate the initial focus event so it's hard to compare. But it doesn't seem so strange that changing focus from within a focus change event would generate a new focus change event. Imagining we don't change WebView's behavior, I would work around this by 1) using an <input type="text" autofocus> instead of <div contenteditable="true">. That would be more elegant anyway, and wouldn't require JavaScript. Or 2) writing my JavaScript to be aware of the 2nd event. (I don't know what "internal logic" this is breaking for you, so I don't know how feasible that is.)
,
Jan 29 2018
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by lge-systemwebview@lge.com
, Jun 27 2017464 KB
464 KB Download
80.0 KB
80.0 KB Download