Skip to content

Conversation

@Piinks
Copy link
Contributor

@Piinks Piinks commented Mar 19, 2021

Originally #75354

Design Document

This change applies Raw/Cupertino/Scrollbars by default on the Web and Desktop platforms. I've done this in a similar way to how we apply the GlowingOverscrollIndicator, in each Widget/Material/Cupertino ScrollBehavior. This allows us to get the right Scrollbar for the given ScrollBehavior.


This current proposal requires a breaking change to ScrollBehavior.buildViewportChrome, adding an optional controller parameter as Scrollbar requires a ScrollController for full functionality. Update: Instead I have deprecated buildViewportChrome in favor of buildViewportDecoration. Breaking the former was a really hard break, so I have introduced a new method, and added an opt-in flag (ScrollBehavior.useDecoration) so customers can be migrated gracefully.

This new method will use (also new) ScrollableDetails to ascertain the right decoration. Passing ScrollableDetails will be a bit more future-proof, where if needed we can add to the details rather than needing to change a function signature. The ScrollableDetails currently contains the required AxisDirection (used for the GlowingOverscrollIndicator decoration), and an optional controller. If a controller is not provided, no Scrollbar will be created.


Some instances of Scrollable are excluded from this including:

  • EditableText
  • ListWheelScrollView
  • PageView
  • NestedScrollView
  • Dropdown menus (they have their own ScrollBehavior that I have, for now, excluded scrollbars from)

To give users control over this, I have added the ability to toggle this feature on and off in ThemeData and CupertinoThemeData. Update: This was a bit over the top, exposing ScrollBehaviors is a cleaner way for users to control defaults. That will be a prerequisite change, in #76739


Blocked by: #76739

Fixes: #40107
Fixes: #70866 (Last part)
Also related as part of ScrollBehavior overhaul: #75728

Pre-launch Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
  • I listed at least one issue that this PR fixes in the description above.
  • I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test exempt.
  • I updated/added relevant documentation (doc comments with ///).
  • I signed the CLA.
  • All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@Piinks Piinks requested a review from goderbauer March 19, 2021 00:39
@flutter-dashboard flutter-dashboard bot added f: cupertino flutter/packages/flutter/cupertino repository f: material design flutter/packages/flutter/material repository. framework flutter/packages/flutter repository. See also f: labels. labels Mar 19, 2021
@google-cla google-cla bot added the cla: yes label Mar 19, 2021
@Piinks Piinks added a: desktop Running on desktop customer: crowd Affects or could affect many people, though not necessarily a specific customer. platform-web Web applications specifically c: API break Backwards-incompatible API changes c: new feature Nothing broken; request for a new capability labels Mar 29, 2021
@Piinks Piinks changed the title WIP Configured ScrollBehaviors for decorating viewports Automatically applying Scrollbars on desktop platforms with configurable ScrollBehaviors Mar 29, 2021
@Piinks Piinks requested a review from goderbauer March 30, 2021 16:08

// Do not use the platform-specific default scroll configuration.
// Dropdown menus should never overscroll or display an overscroll indicator.
// The default scrollbar platforms will apply.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will use the scrollbars defined in ScrollBehavior, but it should be using the ones from the behavior in the context, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see what you mean, I will update the copyWith function to accommodate this.

axisDirection: _isMultiline ? AxisDirection.down : AxisDirection.right,
controller: _scrollController,
physics: widget.scrollPhysics,
physics: widget.scrollPhysics ?? widget.scrollBehavior?.getScrollPhysics(context),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this actually necessary? When widget.scrollPhysics is null, it should be the Scrollable that does this lookup?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yeah, you are right. I guess that makes it a bit redundant here and in Scrollable.

'Temporary migration flag, do not use. '
'This feature was deprecated after v2.1.0-11.0.pre.'
)
bool useDecoration = false,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think we could avoid this flag altogether by making buildOverscrollIndicator just call buildViewportChrome by default?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure what you mean. My plan is to remove buildViewportChrome, so if we are calling it, won't it then take more steps to remove it?
buildViewportChrome may not be just specific to the overscroll indicator for some of our customers currently. I may be misunderstanding. :)

Also, that would make it such that scrollbars will be built before folks have had a chance to migrate to their desired behavior..

@Piinks Piinks requested a review from goderbauer April 1, 2021 19:09
Copy link
Member

@goderbauer goderbauer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM assuming tests on PR and in google pass

🥳 Thanks for sticking with this!

physics: widget.scrollPhysics,
dragStartBehavior: widget.dragStartBehavior,
restorationId: widget.restorationId,
scrollBehavior: widget.scrollBehavior ?? ScrollConfiguration.of(context).copyWith(scrollbars: _isMultiline),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe only do the copy if _isMultiline is true? (This avoids a dependency on the ScrollConfig (which may trigger rebuilds) if we don't need it). If _isMultiline is false, we can just use null as scrollBehvaior to have the lower levels look it up.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's the other way around, if _isMultiLine is true, we want the ScrollBehavior that will apply scrollbars. If it is false, then we copy to remove the scrollbar.

@Piinks Piinks merged commit e40610d into flutter:master Apr 2, 2021
jpnurmi added a commit to jpnurmi/ubuntu-desktop-installer that referenced this pull request Jan 19, 2022
Scrollbars are automatically applied on desktop since flutter/flutter#78588
jpnurmi added a commit to canonical/ubuntu-desktop-installer that referenced this pull request Jan 21, 2022
Scrollbars are automatically applied on desktop since flutter/flutter#78588
@DexEze
Copy link

DexEze commented May 22, 2023

I have found an issue with this change and how it interacts with TabBarView Widgets within a NestedScrollView Widget:

https://stackoverflow.com/questions/76277687/flutter-nestedscrollview-scrollcontroller-is-currently-attached-to-more-than-one/76303348#76303348

Basically on desktop, it causes a scrollbar to be attached to each ScrollView in the tabs, this causes the scroll controller to be connected to more than one tab bar and throws an error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

a: desktop Running on desktop c: API break Backwards-incompatible API changes c: new feature Nothing broken; request for a new capability customer: crowd Affects or could affect many people, though not necessarily a specific customer. f: cupertino flutter/packages/flutter/cupertino repository f: material design flutter/packages/flutter/material repository. framework flutter/packages/flutter repository. See also f: labels. platform-web Web applications specifically

Projects

None yet

Development

Successfully merging this pull request may close these issues.

☂️ Scrollbar Fixes & Updates Scrollbars should be always visible and instantiated by default on web and desktop

3 participants