Status Update
Comments
ap...@google.com <ap...@google.com> #2
First of all thanks for this detailed issue.
This issue had been investigated thoroughly when it was first reported internally. The surprising detail in this report is that the issue is not reproducible before 1.7
. I will look into this.
The main problem with POBox is the fact that it is deprecated. Since 2021 Sony has been shipping new Xperia devices with Gboard pre-installed. Although we are aware that there is still a considerable amount of users still using POBox, the described behavior is caused by POBox's noncompliant behavior with InputConnection
and InputMethodManager
documentation. However, this is understandable since TextView
implementation was also not respecting the behavior that is expected from Editors.
Ultimately we have decided to enforce the documented behavior with specifically regards to when editors should call InputMethodManager.updateSelection
. Also, although unconfirmed, there were traces of possible custom code being included in Sony OEM images that changed how InputMethodManager was notified from TextView. If POBox also depended on something like this, it would be impossible for Compose code to replicate the same unknown behavior.
Description
We added this initially to support storing a press position so that indications (such as
Ripple
) know where to draw the ripple from. Because this just ends up storing a value for a given interaction in a map, there's little safety / guarantee that there is a position, and it is not flexible for other metadata outside of position.Additionally, this causes problems when hoisting
InteractionState
and sharing between components, for example a clickableListItem
that contains aButton
:Because the press position is stored per-Interaction and not local to the component, the same position will be used to draw both ripples. This causes strange effects as the ripples appear to start from different places, and if you click on the bigger component then the ripple on the smaller component will start from outside the bounds of the component, since the position is just an absolute offset.
A more common use case is a
ListItem
with aRadioButton
- this is less bad as theRadioButton
(and other selection controls) use a bounded ripple, so the ripple position never changes - but if clicking on theRadioButton
then the ripple for theListItem
will appear in the wrong place.We should figure out:
a) What the correct / expected behavior is - where the ripple of the other component should begin, and how this can be customized
b) How to change the APIs to support the above