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.
an...@google.com <an...@google.com>
an...@google.com <an...@google.com> #3
Or is that option not available?
Even if the root cause is POBox, from the perspective of the app's customers, it looks like an app bug, so this issue is a blocker against updating Jetpack Compose.
Description
I think we have two issues with misleading behaviour in android.transition.TransitionSet class.
1) setInterpolator of TransitionSet would not propagate an interpolator into the children transitions
Current implementation:
public TransitionSet setInterpolator(TimeInterpolator interpolator) {
return (TransitionSet) super.setInterpolator(interpolator);
}
How it should be (in the same style as setDuration method):
public TransitionSet setInterpolator(TimeInterpolator interpolator) {
super.setInterpolator(interpolator);
if (mTransitions != null) {
int numTransitions = mTransitions.size();
for (int i = 0; i < numTransitions; ++i) {
mTransitions.get(i).setInterpolator(mInterpolator);
}
}
return this;
}
And then in addTransition we should propagate current interpolator, not only duration
public TransitionSet addTransition(Transition transition) {
if (transition != null) {
mTransitions.add(transition);
transition.mParent = this;
if (mDuration >= 0) {
transition.setDuration(mDuration);
}
if (mInterpolator != null) {
transition.setInterpolator(mInterpolator);
}
}
return this;
}
2) Imagine situation when you have a set:
TransitionSet set = new TransitionSet().setDuration(300);
Then you add a lot of transitions into it (that why you want to specify duration not one by one but only once for the set via .setDuration(300)).
And then you also want to add one more transition but with a smaller duration:
Fade fadeIn = new Fade(Fade.IN);
set.addTransition(fadeIn);
fadeIn.setDuration(100);
But it not works, fadeIn is animating with duration 300.
Its a real usecase, sometimes we need a set with for example a lot of ChangeBounds with the same duration and one visibility in animation with a smaller duration(and one visibility out animation with smaller duration)
The reason of it is a clone method:
public TransitionSet clone() {
TransitionSet clone = (TransitionSet) super.clone();
clone.mTransitions = new ArrayList<Transition>();
int numTransitions = mTransitions.size();
for (int i = 0; i < numTransitions; ++i) {
clone.addTransition((Transition) mTransitions.get(i).clone());
}
return clone;
}
Here we call addTransition where we would override the duration of the transition again.
To fix it I suggest to change the line
clone.addTransition((Transition) mTransitions.get(i).clone());
to:
Transition transition = (Transition) mTransitions.get(i).clone();
clone.mTransitions.add(transition);
transition.mParent = clone;
Thanks,
Both issues were found during the development of transitions backport library Transitions-Everywhere