IssueTracker

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:

1. Calculate the union of the ongoing and new requested rectangles.
2. If the responder has room to fit the entire union on screen, the merge result is the union.
3. Else the merge result is the newer rectangle.

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.