Scrollbar should not execute fade in/out animation if it is always visible #116212
Labels
f: scrolling
Viewports, list views, slivers, etc.
found in release: 3.3
Found to occur in 3.3
found in release: 3.6
Found to occur in 3.6
framework
flutter/packages/flutter repository. See also f: labels.
has reproducible steps
The issue has been confirmed reproducible and is ready to work on
P2
Important issues not at the top of the work list
team-framework
Owned by Framework team
triaged-framework
Triaged by Framework team
Comments
|
Reproducible using the code sample provided above. Screen.Recording.2022-11-30.at.10.43.32.movLabeling for further investigation. flutter doctor -v |
danagbemava-nc
added
framework
|
cc @Piinks |
|
Hi @AsturaPhoenix, thanks for reporting! I altered your code sample just a little bit to make it clearer what I think is happening here - I made the provided color red so it really stands out when it is or isn't using the value, instead of black since there is an opacity animation and varying shades of gray otherwise. import 'package:flutter/material.dart';
void main() {
runApp(
MaterialApp(
theme: ThemeData(
scrollbarTheme: ScrollbarThemeData(
thumbColor: MaterialStateProperty.resolveWith(
(states) => states.isEmpty ? Colors.red : null,
),
thumbVisibility: const MaterialStatePropertyAll(true),
),
),
home: Scaffold(
body: SingleChildScrollView(
child: ConstrainedBox(
constraints: const BoxConstraints(minWidth: double.infinity),
child: Text('content\n' * 500),
),
),
),
),
);
}I don't think this is specific to the hover behavior, but more so the fade in/out animation. If the color is red when there are no states, and the thumb is set to always be visible, it should not be executing the fade in/out animation at all like we can see in the video above. |
Piinks
changed the title
|
@Piinks Thanks for looking at this! I wouldn't go so far as to say that the fade animation should not execute at all. Here's what the animation looks like with this issue patched on my fork: localhost_54796_._.-.Google.Chrome.2022-12-07.12-19-54.mp4Are you saying the intended behavior would be to immediately change the color from red to the default hover color of semitransparent black on hover? I wouldn't expect that from just overriding the colors or visibility, though I do recall seeing that as the behavior if the track is shown. I think I prefer having the animation, though that may just be from being used to seeing it. |
This was referenced Apr 4, 2023
flutter-triage-bot
bot
added
team-framework
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When the idle or hover color of a scrollbar is overridden with
thumbColor: MaterialStateProperty.resolveWith, the color fade animation seems to misbehave:This seems to be because the lerp always uses the current state rather than lerping between the current and previous states, while still falling back to the state-appropriate default colors when not overridden:
flutter/packages/flutter/lib/src/material/scrollbar.dart
Lines 336 to 340 in 8b32ac7
It looks like we can fix this by hard-coding the states to:
Steps to Reproduce
https://dartpad.dev/e8945563710b4d755944cb3f4ac90d1d
Expected results:
Smooth blending between overridden and default states.
Actual results:
Discontinuous blending using default colors, or skipped animations.
This occurs on both stable and master.
Code sample
Logs
The text was updated successfully, but these errors were encountered: