+changwan to confirm restartInput is supposed to happen when webview gets focus?

r98525087t2@gmail.com: you have a video of this? are you sure if a input field in the webview is in focus?

This sounds a bit similar to crbug.com/619562

Updated WebView to 52.0.2743.41 and provide two videos (a_IssueReproduce_0620 and b_IssueRecover_0620). On a_IssueReproduce_0620, the issue only happens on 00:14. The problem can be recovered by a tap on IME or WebView to regain focus on b_IssueRecover_0620. We also check the WebView is focused on issue occurs.

Deleted: a_IssueReproduce_0620.mp4 6.4 MB

	a_IssueReproduce_0620.mp4 6.4 MB View Download

Deleted: b_IssueRecover_0620.mp4 9.3 MB

	b_IssueRecover_0620.mp4 9.3 MB View Download

Deleted: Hierachyviewer from 2016-06-20 10:27:10.png 1017 KB

	Hierachyviewer from 2016-06-20 10:27:10.png 1017 KB View Download

Deleted: Screenshot from 2016-06-20 10:27:10.png 286 KB

	Screenshot from 2016-06-20 10:27:10.png 286 KB View Download

Due to upload files limit, we upload bugreport on https://drive.google.com/file/d/0B6ToBcix11ctdkRNNkQtM19GQ2M/view?usp=sharing

We do not have an HTC phone in the Seoul office, so I cannot reproduce this locally.

My initial suspicion is that there are complicated view focus change + editable node change happening at the same time.

What is the sequence of the following when the issue reproduces / does not reproduce?
1) HTC email calls showSoftKeyboard()
2) WebView calls hideSoftKeyboard()
3) WebView calls restartInput()
4) WebView gets onFocusChanged(false)
5) WebView gets onFocusChanged(true)
6) DOM gets onfocus event.

Could HTC provide a sample apk (with source code) to reproduce this issue better?

There exists a public APK https://play.google.com/store/apps/details?id=com.htc.android.mail , could you check if the issue reproduces on that one?

Unfortunately, it's available only to HTC devices.

This APK works fine for me on my Nexus 5X running MOB30O: http://www.apkmirror.com/apk/htc-corporation/htc-mail/htc-mail-9-50-722647-release/htc-mail-9-50-722647-android-apk-download/

I can repro the issue shown in the video sometimes, the cursor doesn't blink after pressing "reply".

Provided sample code for this case.

We also find this problem sometimes happens on reply on read view (with webview component as a_IssueReproduce_0620), but cannot reproduce on long press on list view on c_CannotReproOnListView_0621.mp4.

We let the cursor on first position by JavaScript. Not sure does it related webview usage on previous activity?

Deleted: DemoSourceCode.java 0 bytes

DemoSourceCode.java 0 bytes View Download

Deleted: c_CannotReproOnListView_0621.mp4 8.6 MB

	c_CannotReproOnListView_0621.mp4 8.6 MB View Download

Attached demo source code, again.

Deleted: DemoSourceCode.java 6.5 KB

DemoSourceCode.java 6.5 KB View Download

Thanks for the APK! I was able to reproduce the issue. Also thanks for sharing the code. The below analysis is based on the APK, not the source code, though.

It seems that the editable node does not get focus. That's why the cursor does not appear on the screen. Also as a result of this failure, ImeAdapter#focusedNodeChanged() does not get called, and we do not restart input.

When it works correctly,

Step #1. View focus gets propagated to blink.
WebView#onFocusChanged(true) → … → content::RenderViewImpl::SetFocus() → … → blink::WebViewImpl::setFocus(true) → … → blink::FrameSelection::setFocused()

Step #2. JavaScript focuses on the editable node.
WebView#loadUrl(“javascript:...”) (assumed) → … → blink::DOMSelection::addRange() → blink::FrameSelection::setFocusedNodeIfNeeded()

Step #3. Focused node change gets propagated from Blink to browser process.

RenderViewImpl::focusedNodeChanged() → … → ImeAdapter#focusedNodeChanged() → InputMethodManager#restartInput()

When it does not work, step #2 -> step #1, but step #3 is not called because frame selection is not focused yet.

Now that I see the sample source code, it seems that HTC gives focus to the editable node immediately after page has been loaded. However, view focus has not yet been delivered to the Blink internally.

Especially so because  InputMsg_SetFocus is an input message, and input event filter posts it on the compositor impl thread first. The original issue can be mitigated if we change it to ViewMsg or FrameMsg. (I also tried reverting my message reordering change of https://codereview.chromium.org/1877073003, but it still reproduces).

I'm not sure about the implication of changing SetFocus to FrameMsg, though.
It's been there more than 4 years ago.

BTW, could HTC try autofocus instead of adding range? What is the reason of doing so?

Hi changwan,
Thanks for sharing your study and suggestions. It works when change to "document.body.focus();"

aelias@, there is a chance that WebView's JavaScript execution may not work correctly if it was called immediately after adding WebView or giving view focus to it because SetFocus is an input-typed message. (although in this case it seems that it could be worked around...) Do we need to fix this? If so, would it be ok to change the message type?

I haven't heard a strong enough reason to make any change to WebView here.  I don't want us to commit to any additional ordering guarantee unless it's truly required.  I think the app developer should be able to make this work properly by waiting on the right signals instead of blasting the calls without waiting.

Re #14, thanks for the quick answer.

Then HTC actually just needs to wait for window focus:

function onFocus(event) {
  setCaretPosInBeginning();
  // or document.body.focus();
}

window.addEventListener('focus', onFocus, false);

It's somewhat not clear that there is a state where window does not have focus initially even when onPageFinished() was called. But this is something that we can't fix at the moment.

Let me close this bug now.