@mcomella: Thanks for the report!!

Could you please update Chrome to latest version #65.0.3325.109 and check if you still face the issue? If so please attach a screencast for further triaging of the issue.

Thanks!!

I still face the issue after updating to 65.0.3325.53 [1]. Here's a screen-cast of me reproducing: https://drive.google.com/open?id=172syquaWhOGEc_fguOr9EeblkFC8rCGk

What happens in this video is:
- I navigate with the keyboard to the banner image (down arrow twice on the keyboard)
- I wait for my code to automatically move focus from the WebView to another View and back to the WebView again
- Watch the terminal on the bottom-right: it prints out which views are focused in the DOM (via document.activeElement). Notice it goes from the banner image (as a URL) to [object HTMLHtmlElement] when focus returns to the WebView.
- I click the down arrow again, which should move from the banner to the textbox. Instead, it highlights "Privacy", at the bottom

[1]: It's not the most recent, but it's the best I can do. I need a keyboard/dpad to modify focus and I don't have any devices available besides the emulator, which can't update the WebView version it comes with. I pulled down the P system image, which is the most recent one.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue seems to be out of TE scope as we need to check this issue using emulator.

Adding Mobile>WebView component for further triage.

Thanks!!

> This issue seems to be out of TE scope as we need to check this issue using emulator.

I believe you'd also be able to reproduce with a bluetooth keyboard - I just don't have one lying around. But it would be easiest to reproduce with my test app.

So is this specifically with focus of the DPAD navigation thing? Would it be easier to check dom element focus from js? That's probably easier for us than finding a keyboard. Although I don't know if dom element focus and the DPAD thing are exactly the same.

And when you switch focus away, you are switching android view focus? Window focus lose then restore (going to app switcher then back) doesn't not cause this behavior.

> So is this specifically with focus of the DPAD navigation thing? Would it be easier to check dom element focus from js?

I briefly tried reproducing this solely with JS [1] but I was unable to. As such, I expect this might just be related to how Android handles keyboard focus.

> And when you switch focus away, you are switching android view focus?

Right. In my STR, at the Android level, the WebView starts with the focus and at the browser level, whatever is selected with the keyboard is focused. After a few seconds, my code moves focus at the Android level to a sibling Android View (and the element remains focused at the browser level). A few seconds later, when my code requests focus back to the WebView at the Android level, the element focused at the browser level loses focus, which I don't expect to happen.

> Window focus lose then restore (going to app switcher then back) doesn't not cause this behavior.

I'd expect this to be the case: Android maintains the focus state when clicking-home/returning to the app or switching between them.

[1]: https://github.com/mcomella/firefox-tv-issue393/blob/b76794390d126590e99ea8f97a532b31c1be0dd1/app/src/main/java/xyz/mcomella/webviewevaljs/MainActivity.kt#L33

I also do not have a keyboard handy but I wonder if adb would work. (E.g. "adb shell input keyevent DPAD_DOWN") Can you check if you can repro that way?

I wasn't able to build the github project so I refactored it into an Android Studio project (sources attached).

I get no repro using the attached project, adb-simulated d-pad, Android P preview, Pixel 1 XL, WebView 65.0.3325.16. I can move focus both before and after the timed focus changes.

Deleted: firefox-tv-issue393.tar.xz 1.6 KB

firefox-tv-issue393.tar.xz 1.6 KB Download

> I wonder if adb would work. (E.g. "adb shell input keyevent DPAD_DOWN") Can you check if you can repro that way?

I was able to reproduce on my Pixel Android P emulator, 65.0.3325.53. Unfortunately, atm I don't have a device handy but I can try to find one if you need me to test on a real device.

Repro notes:
- The unfocus and refocus is automated and the timing is tight: be sure to have focused another view in time (e.g. by reading the logcat output)
- One I send one key down event and filter logcat on "lol", this is my logcat output:

04-02 23:21:17.625 4367-4367/xyz.mcomella.webviewevaljs D/lol: onPageFinished
04-02 23:21:22.628 4367-4367/xyz.mcomella.webviewevaljs D/lol: unfocus webView
04-02 23:21:23.635 4367-4367/xyz.mcomella.webviewevaljs D/lol: request focus back to WebView
04-02 23:21:23.639 4367-4367/xyz.mcomella.webviewevaljs I/chromium: [INFO:CONSOLE(1)] "lol: [object HTMLDivElement]", source:  (1)
04-02 23:21:23.640 4367-4367/xyz.mcomella.webviewevaljs I/chromium: [INFO:CONSOLE(1)] "lol: [object HTMLHtmlElement]", source:  (1)

Note: there is no visible rect highlighted on the page when I do this but the logcat indicates the focus is not happening as expected. If you send two down events, instead of one as I did, it will clearly put the focus rect on one of the views in the page which disappears when the WebView regains focus.

> I wasn't able to build the github project so I refactored it into an Android Studio project

This is surprising: my project is an Android Studio project. I made a fresh clone and have no problems opening and running it. What errors are you seeing?

Yep, I get that same sequence in the logcat, and the d-pad events still work afterwards. Using WebView 65.0.3325.109 this time.

Curiously, while I can DPAD_DOWN from the WebView into the TextView, I can't DPAD_UP from the TextView back to the WebView.

It might be specific to the emulator. Could you try on a physical device?

It also might be specific to Android TV. What device/emulator form factors have you tested?

> Yep, I get that same sequence in the logcat, and the d-pad events still work afterwards.

To be explicit, my concern is that DOM focus is reset when the WebView loses Android focus programmatically and regains Android focus programmatically. I would expect the d-pad events to continue to work, as they do for me.

> Curiously, while I can DPAD_DOWN from the WebView into the TextView, I can't DPAD_UP from the TextView back to the WebView.

This is outside the scope of my issue.

> It might be specific to the emulator. Could you try on a physical device?

If you receive the same log output, it sounds like you've been able to reproduce my issue: why do you think this is necessary?

Perhaps we don't have a shared understanding of what my problem is. I think this sums it up succinctly: "...my concern is that DOM focus is reset when the WebView loses Android focus programmatically and regains Android focus programmatically." Does that makes sense? I can try to provide an STR that makes this clearer: let me know.

> It also might be specific to Android TV. What device/emulator form factors have you tested?

I reproduced on an API 22 Pixel emulator (with WebView ~39) and on a API 26 Pixel 2 XL with WebView 58. I've also reproduced on an Android TV emulator and an Amazon Fire TV with their WebView fork (AmazonWebView) but I don't have the specific version details at the moment.

Sorry, I thought the bug was the d-pad not working. I can repro the issue with a pair of <input> fields; the focus resets to the first one, even if the second was focused before.

ctzsm@, could you take a look?