Status Update
No update yet.
Comments
wj...@gmail.com
I don't think this falls under pointer input so this is simply less tied to the area I've been focusing on. I think this should be considered open for anyone else to start working on. I think the two main areas of work for keyboard input are building out the equivalent of focusableInTouchMode and routing keyboard input events to the appropriate node/modifier.
Is this something that Semantics should handle? Seems that if it did, both keyboard events, auto fill, google assistant, could all use the same mechanism to send text data to the ui.
Is this something that Semantics should handle? Seems that if it did, both keyboard events, auto fill, google assistant, could all use the same mechanism to send text data to the ui.
an...@google.com
an...@google.com
Hey Shep, thanks for the info.
For the ticket itself it is a reminder for us that is not prioritized yet.
For editable text (TextField) this should already work since IME handles it.
However I am not sure if and when we want to support what Android has (things like menu shortcuts).
Happy to hear from Ryan and Ralston in case this subject was discussed before.
For the ticket itself it is a reminder for us that is not prioritized yet.
For editable text (TextField) this should already work since IME handles it.
However I am not sure if and when we want to support what Android has (things like menu shortcuts).
Happy to hear from Ryan and Ralston in case this subject was discussed before.
wj...@gmail.com
I don't think this is/should be within Semantics's domain. Hardware keyboard input should, as far as I know, follow the same path as (and is, as far as I understand it, indistinguishable from) soft keyboard input (in fact, Gboard actually interacts with hardware keyboards).
I also don't think we want autofill/assistant to actually send keyboard events. That could lead to very strange results as well as maybe performance issues - consider it trying to send dozens of key events instantaneously. I'd think we'd want it to fill text fields directly via some other mechanism (probably an action callback).
I also don't think we want autofill/assistant to actually send keyboard events. That could lead to very strange results as well as maybe performance issues - consider it trying to send dozens of key events instantaneously. I'd think we'd want it to fill text fields directly via some other mechanism (probably an action callback).
an...@google.com
Ah, I based on Siyamed's comment, this bug is intended to track the work necessary to handle keyboard events that aren't related to IME. (like menu shortcuts). I'm not sure what is needed here.
Description
What
User experience
What type of Android issue is this?
Display or Rendering
What steps would let us observe this issue?
What was the effect of this issue on your device usage, such as lost time or work?
High
When
Time and frequency
When did this happen?
Dec 18, 2024 GMT+08:00
How often has this happened?
Frequently
Where
Component
Originating component: <not visible> (1630575)
Build and device data
- Build Number: google/caiman_beta/caiman:15/BP11.241121.013/12873528:user/release-keys
(Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)
Debugging information
Google Play services
com.google.android.gms
Version 245034036 (24.50.34 (260408-713002902))
System App (Updated)
Android System WebView
com.google.android.webview
Version 683407942 (132.0.6834.79)
System App (Updated)
Network operator: China Unicom
SIM operator: NTT DOCOMO
Network operator: China Unicom
SIM operator: UNICOM HK
Filed by Android Beta Feedback. Version (Updated): 2.46-betterbug.external_20241023_RC01 (DOGFOOD)https://developer.android.com/preview/feedback#feedback-app .
To learn more about our feedback process, please visit