Version 0.6, when using TAB to switch web elements, it may be blocked by a control with the class name WRY_WEBVIEW

[mzdk100]

Problem

Specifically, when a user switches focus within a web element using the keyboard's tab, if they continue to press the tab after switching to the last web element, the focus will jump to the control with the class name WRY_WEBVIEW. At this point, no matter how much they press the tab, they cannot continue switching web elements; The solution to this problem is to first switch to another application (such as the desktop), and then switch to the dioxus application again. At this point, the system will reset the focus to the web document, and you can continue to use the tab to switch elements, but this requires the user to operate it themselves, and the experience is very poor.

• Importantly, this bug does not exist in version 0.5.6.

Steps To Reproduce

Steps to reproduce the behavior:

Refer to the description above.

Expected behavior

The control with the class name WRY_WEBVIEW should not be allowed to grab keyboard focus, so that the tab key can be used to cyclically switch web elements.

Screenshots

Environment:

• Dioxus version: 0.6.*
• Rust version: 1.80.1
• OS info: Windows 10 22H2 (10.0.19045) workstation AMD64
• App platform: desktop

Questionnaire

• [ ] I'm interested in fixing this myself but don't know where to start
• [ ] I would like to fix and I have a solution
• [ ] I don't have time to fix this right now, but maybe later

[matthunz]

Is WRY_WEBVIEW a container for Dioxus desktop apps? @ealmloff If we need to have it I’m wondering if setting tabindex=-1 would fix this 🤔

[ealmloff]

Is WRY_WEBVIEW a container for Dioxus desktop apps? @ealmloff If we need to have it I’m wondering if setting tabindex=-1 would fix this 🤔

We don't create WRY_WEBVIEW, but I do see some instances of it in wry which was updated since 0.5. It might be an upstream issue

[mzdk100]

Yes, it is container for webview's document. However, I cannot control the focus of this control.