Status Update
No update yet.
Comments
ma...@google.com
kl...@google.com
kl...@google.com
1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?
kl...@google.com
Tested on Android 12 Emulator with custom executor, but cannot repro this issue.
ap...@google.com
-
Second crash in the description is from a real device. Experienced it myself on two different Xiaomi phones, plus lots of crashes from users in the Google Play console.
-
Dynamic features are not used in the application.
As a wild guess, I have downgraded build tools from 31.0.0 to 30.0.3, compileSdk from 31 to 30, and moved all work with Language ID to the service in a separate process (just to be sure that crash can kill secondary process instead of main). This combination is in beta for 2 days by now and I don't see any SIGSEGV crashes.
ap...@google.com
Hmm, I feel the crash might be something related to separate/secondary process.
I also changed compileSdk and targetSDK to 31 but still cannot repro this issue.
Description
If two requests are made concurrently on the same BringIntoViewRequester, if the responder is using standard animation APIs (like scrollable is) then the last request to be processed will cancel all the animations for the other requests.
This currently happens when text fields gain focus. Consider a text field with a large decoration box (eg a material text field). The focusable first gets the focus event and makes a request to bring the entire decoration box into view. Then the text field gets the focus event and makes a request to bring the cursor area into view. The cursor area is always inside the decoration box. If the cursor area is already in view, that second request noops and the first request completes, bringing the entire decoration box into view. However, if the cursor area started off hidden (as is common, eg if the entire text field would be covered by the newly shown keyboard), then the second request cancels the first and only the cursor area is brought into view, which means part of the decoration box will stay clipped.
I think the solution is that the bring into view responder should detect when a request comes in while a previous request is still being processed, somehow calculate the merge of the two requests, and only cancel the animation if it needs to adjust it to handle the merge result.
The merge algorithm might look something like this:
In particular, in the case where the entire text field can fit in the responder, this algorithm would always prioritize requests for bringing the entire text field into view over requests to bring the cursor into view.
This logic must happen at each responder node. Because text fields contain their own scrollable below the focusable, even if the cursor request will be ignore by a scrollable much higher up in the tree, the text field's own scrollable still needs to process it.