New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The calculation method for _CriticalSolution seems wrong #109675
Comments
Labeling for further insight from the team. |
I agree this is wrong. I found it as part of investigating #120338, when I went and audited all the simulations the framework uses for scroll physics to try to confirm that each one was consistent with the scroll protocol's invariant #120341 that requires the scroll physics to make at least a certain kind of sense physically. One consequence of this bug is that it does not satisfy that invariant. Another salient consequence of this bug is that the simulation's actual initial velocity can be very different from the requested initial velocity
I have not yet tried to exercise this behavior in the context of an app. I'm not yet sure exactly what effect it has for users. |
Looking closer, I think in fact we never actually use As a result, this will not affect any app unless it calls a There are four
So, left to its own devices, the framework only ever uses If an app does create a critically-damped I have a fix for this issue. I'll send a PR. |
Fixes flutter#120341. The scroll protocol makes an important assumption about the behavior of ScrollPhysics implementations, and this requirement hasn't been clearly documented. Add documentation for it. Parts of the text are modelled on similar language at StatelessWidget.build and StatefulWidget.build. It does feel a bit uncomfortable to juxtapose this description of a required invariant with three issues where the framework doesn't satisfy it. Fortunately two of them apply by default only in uncommon cases: flutter#120340 macOS touchpad flinging, and flutter#109675 never. The third is flutter#120338, affecting default scrolling on Android and other non-Apple platforms. I'll send a PR to fix that shortly, and another for flutter#109675. As discussed at flutter#120338, it's quite possible we'll remove this invariant in the future. But that's been attempted before, and is complicated: the invariant is a useful one. Removing it would almost certainly involve a breaking change for ScrollPhysics subclasses. So I think even if we had an immediate plan to remove it, we'd need some kind of documentation for it, if only to explain the breaking change.
Fixes #120341. The scroll protocol makes an important assumption about the behavior of ScrollPhysics implementations, and this requirement hasn't been clearly documented. Add documentation for it. Parts of the text are modelled on similar language at StatelessWidget.build and StatefulWidget.build. It does feel a bit uncomfortable to juxtapose this description of a required invariant with three issues where the framework doesn't satisfy it. Fortunately two of them apply by default only in uncommon cases: #120340 macOS touchpad flinging, and #109675 never. The third is #120338, affecting default scrolling on Android and other non-Apple platforms. I'll send a PR to fix that shortly, and another for #109675. As discussed at #120338, it's quite possible we'll remove this invariant in the future. But that's been attempted before, and is complicated: the invariant is a useful one. Removing it would almost certainly involve a breaking change for ScrollPhysics subclasses. So I think even if we had an immediate plan to remove it, we'd need some kind of documentation for it, if only to explain the breaking change.
Fixes flutter#109675. This formula would produce an initial velocity quite different from the one specified as an argument. To update the test, I computed the expected results separately by using the physical formula. Happily, the framework by default never ends up actually exercising this code. Of the four SpringDescription call sites within the framework, two are explicitly overdamped; the other two are by design critically damped, but due to rounding they end up being treated as (very slightly) overdamped too. Details here: flutter#109675 (comment) So the only way an app could be affected by this bug is if it called a SpringDescription constructor itself, and managed to create a spring description where the distinguishing formula in _SpringSolution comes out exactly equal to zero. It's likely nobody has ever shipped such an app, because the behavior this produces would be so wildly wrong that it'd be hard to miss when exercised.
Fixes #109675. This formula would produce an initial velocity quite different from the one specified as an argument. To update the test, I computed the expected results separately by using the physical formula. Happily, the framework by default never ends up actually exercising this code. Of the four SpringDescription call sites within the framework, two are explicitly overdamped; the other two are by design critically damped, but due to rounding they end up being treated as (very slightly) overdamped too. Details here: #109675 (comment) So the only way an app could be affected by this bug is if it called a SpringDescription constructor itself, and managed to create a spring description where the distinguishing formula in _SpringSolution comes out exactly equal to zero. It's likely nobody has ever shipped such an app, because the behavior this produces would be so wildly wrong that it'd be hard to miss when exercised. Co-authored-by: Kate Lovett <katelovett@google.com>
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of |
Steps to Reproduce
Expected results:
Actual results:
Code sample
Logs
The text was updated successfully, but these errors were encountered: