Details
-
Bug
-
Resolution: Done
-
P2: Important
-
5.11
-
None
-
Windows 10 with touch-screen based PCs.
-
-
3d867b84a3ac4c2b32b7d476eaeadc2c7fae277b
Description
It seems a recent Windows 10 update has changed the way in which the Windows On-Screen Keyboard detects that a UI widget is a text editing widget, breaking the automatic showing/hiding of the OSK for Qt applications, which was added in Qt 5.11. Until recently, according to tests performed on a Surface Notebook running Windows 10, UI Automation was active from the start for all applications, and just reporting that a widget element supported the Text Provider control pattern was enough for the automatic showing/hiding of the OSK to work. However, it seems that after the system was updated, UI Automation is not enabled from the start for applications, but only when an accessibility application such as Narrator is running. And even then, UI Automation is not being used by the OSK to determine if it should appear. The change was likely for performance reasons, to avoid the overhead of having UI Automation ruining all the time with touch-screen based devices when accessibility tools are not running. Unfortunately, I couldn't find documentation on the changed behavior (it is not an issue for applications with native widgets). However, tests performed on the system have shown that by showing a text caret on the text widget, by calling CreateCaret()/SetCaretPos()/ShowCaret(), when it gains focus, the OSK is triggered. Since Qt renders its own text caret, we could use an invisible system caret to trigger it, by initializing it with a transparent bitmap.
Attachments
Issue Links
- relates to
-
QTBUG-89354 When the native virtual keyboard shows up, it does not shift the Qt Quick Window up in order to show where the cursor is in the text input field
- Reported
- resulted in
-
QTBUG-74492 QWebEngineView: A blinking white dot displays on dark website
- Closed