Scrollbars should be always visible and instantiated by default on web and desktop

As mentioned in #38795, the the browser's scrollbar isn't currently visible when content can be scrolled. Ideally, we'd show the scrollbar when content can be scrolled otherwise this breaks users expectations on the platform.

Any active development is in progress for this feature. We are using Flutter widget as a component in existing web page but the issue is it is disabling browser scrollbar.

I am trying to get a clarification since there is no milestone setup for the Flutter for the web to have the default scrollbar visible. Is this something that is planned for Flutter for the web to handle?

Thank you.

I am trying to get a clarification since there is no milestone setup for the Flutter for the web to have the default scrollbar visible. Is this something that is planned for Flutter for the web to handle?

Thank you.

You'll just have to follow this issue to keep track of the progress. Since there is no milestone assigned it likely isn't at the top of the list and/or it isn't easy to implement. So I'd say at this point, I wouldn't expect this to get resolved anytime soon.

@jaredbaszler

@jaredbaszler Thanks...

That's a big issue to address. I picked up flutter with the goal of rendering "web first" and then other devices. Meaning that if web does not work for me it's a big issue. My MVP depends on web working successfully in the early MVP life time and less so on the mobile platforms. Scrolls are super important for UX. I find this is an essential feature to have for the web. Please add priority to this request.

The app fails while trying to drag the Scrollbar when used with SliverList.

Code:

  Scrollbar(
      controller: _scrollController,
      child: CustomScrollView(
        controller: _scrollController,
        physics: const ScrollPhysics(),
        slivers: <Widget>[
          SliverList(
            delegate: SliverChildBuilderDelegate((BuildContext context, int index) {
              if (index >= itemLength) {
                return null;
              }

              return Container( width: 20);
            }),
          ),
        ],
      ),
    );

Screen recordings:

My observation:

Scrolling using trackpad doesn't break the app
Drag and scroll results in app crash.
I was able to pull the scrollbar out of the app window a couple of times (the app crashes soon after).
For a list with a lot of rows the scroll bar doesn't show up until we reach the bottom (the app crashes soon after dragging the scrollbar)

Error:

flutter: �[38;5;196m│ �[0m�[39m�[48;5;196m'package:flutter/src/rendering/viewport.dart': Failed assertion: line 1522 pos 12: 'correctedOffset.isFinite': is not true.�[0m�[49m
flutter: �[38;5;196m├┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄�[0m
flutter: �[38;5;196m│ #0   _AssertionError._doThrowNew (dart:core-patch/errors_patch.dart:46:39)
flutter: �[38;5;196m│ #1   _AssertionError._throwNew (dart:core-patch/errors_patch.dart:36:5)
flutter: �[38;5;196m│ #2   RenderViewport._attemptLayout (package:flutter/src/rendering/viewport.dart:1522:12)
flutter: �[38;5;196m│ #3   RenderViewport.performLayout (package:flutter/src/rendering/viewport.dart:1479:20)
flutter: �[38;5;196m│ #4   RenderObject._layoutWithoutResize (package:flutter/src/rendering/object.dart:1634:7)
flutter: �[38;5;196m│ #5   PipelineOwner.flushLayout (package:flutter/src/rendering/object.dart:884:18)
flutter: �[38;5;196m│ #6   RendererBinding.drawFrame (package:flutter/src/rendering/binding.dart:453:19)
flutter: �[38;5;196m│ #7   WidgetsBinding.drawFrame (package:flutter/src/widgets/binding.dart:870:13)
flutter: �[38;5;196m

flutter --version

Flutter 1.26.0-2.0.pre.419 • channel master • https://github.com/flutter/flutter.git
Framework • revision 913d5933c1 (89 minutes ago) • 2021-01-19 22:34:03 -0800
Engine • revision b58dbc88fc
Tools • Dart 2.12.0 (build 2.12.0-240.0.dev)

flutter doctor

[✓] Flutter (Channel master, 1.26.0-2.0.pre.419, on macOS 11.1 20C69
    darwin-x64, locale en-GB)
[✓] Android toolchain - develop for Android devices (Android SDK version
    30.0.3)
[✓] Xcode - develop for iOS and macOS

@ganeshrvel

@ganeshrvel can you please file a new issue with a reproduction of your issue? This issue for for a separate feature. Thank you!

@Piinks

@Piinks created: #74404

Yes! I think on web and desktop they should be visible by default (when needed). Of course with option to hide

If it when needed, then it is not always visible

On some platforms (Windows) there is a system preference for if scrollbars should auto-hide or not.

I understand we are not having scrollbars at all and respecting settings like this one is the cherry on top. But just pointing out that this system setting exist. Similar to how an app preferable respect system dark mode setting.

I have a proposed solution in #75354
Although I am not sure this is the best idea to implement so I'm requesting any feedback or input. :)

Here are my concerns with auto-generated Scrollbars:

users will be annoyed by Scrollbars showing up where they are not wanted
users that are already using Scrollbars on desktop/web will be broken by duped Scrollbars (if the user implements a Scrollbar, ti will be duped by the auto-scrollbar)
users implementing or extending ScrollBehavior.buildViewportChrome will be broken
creating scrollbars on mobile will require the user to add special handling when their app in on web/desktop, lest be affected by the duped scrollbar exception mentioned above
- or they could turn off autoScrollbars all together and have no issue - which I think kind of nullifies the point of this feature.

Also, I don't think we can automatically detect a Scrollbar created by the user. They can be placed anywhere in the tree, and even if we could track them all down, we would need to distinguish which were made automatically and which were user generated.
Also, there is already a pattern of use where the Scrollbar listens to more than one Scrollable. I've seen this most often with 2D scrolling.

Please see the change (#75354) for more context. All input is welcome while we try to decide the best way to proceed here. :)

In response to request for comments.

Your values state:

Our first priority is to our developer's user, the end user. Our second priority is to our user, the developer.

On desktop and desktop web end users of software use a vairity of input devices. A mouse with a scroll wheel is common, but it cannot be expected that every user has that. For example I use a trackball which do not have a scroll wheel, instead I use the scroll bars and hold a button and scroll by rolling the ball which has infinite movement by design. Other users may be using other devices for accessibility like voice control with eye mouse or a grid mouse.

Basically, there are a vast vairity of users out there and not every developer is able to understand or anticipate the impact of not adding a scroll bar to their app. So the framework need to be accessible by default in order for most apps to have good accessibility. Then of course I'm not against flags to allow a developer to hide scrollbars if their app is a digital signage app or other situation where they know the scrollbar is not desired. But I think developers should need to opt-out of it. Which could be as simple as a property with a default value.

@Piinks

@Piinks is there any expected date to your pr being implemented on any of the branchs?

I am also looking for an update, especially for Flutter Web. I have a production app that really needs this feature.

Thank you.

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 flutter doctor -v and a minimal reproduction of the issue.

Navigation Menu

Repository navigation

Scrollbars should be always visible and instantiated by default on web and desktop #40107

20 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Scrollbars should be always visible and instantiated by default on web and desktop #40107

Description

Activity

sudip4036 commented on Dec 12, 2019

Sun3 commented on Sep 18, 2020

jaredbaszler commented on Sep 18, 2020

Sun3 commented on Sep 18, 2020

adrian-moisa commented on Oct 4, 2020

20 remaining items

ganeshrvel commented on Jan 20, 2021

Piinks commented on Jan 20, 2021

ganeshrvel commented on Jan 21, 2021

arualana commented on Jan 23, 2021

Leffe108 commented on Jan 24, 2021

Piinks commented on Feb 4, 2021

Leffe108 commented on Feb 6, 2021

Macacoazul01 commented on Feb 10, 2021

Sun3 commented on Feb 15, 2021

github-actions commented on Aug 3, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions