"Reject mouse drags by default in scrollable", breaks apps past behavior

@mariamhas

Reject mouse drags by default in scrollable, breaks apps past behavior

This new default behavior that just landed in master channel "reject mouse drags by default in scrollable" via #81569 breaks past and expected Flutter de-facto default behavior.

Please keep this new change as an explicitly opt-in new feature
Don't make it one that breaks past prior default and already now expected and established default behavior. As a general principle, if not absolutely necessary don't change past behavior, new features should require opt-in.

I agree that the new behavior is more correct behavior for desktop apps. However, for the past +2 years this has not been the default behavior in Flutter desktop and web applications, thus creating a de-facto default expected behavior, that users have even gotten used to, and to some extent even like, so much that they now complain when it is gone.

New apps that do not want to have this Flutter "device" like behavior on desktop/web, should choose to opt-in to not use it and get the more real desktop/web like behavior, while apps already running should continue to behave as before unless they also opt-in to this new feature.

There probably is no past Flutter internal test for this that would break, but again the change does break de-facto established and in production used and expected Flutter app behavior.

Steps to Reproduce

When building with master channel 2.3.0-1.0.pre.226 or later, scrollable surfaces can no longer be drag scrolled with a mouse on desktop and web builds, nor can eg tab views be dragged with a mouse. This still works as before and expected in other channels dev 2.3.0-0.1.pre, beta 2.2.0-10.2.pre and stable 2.0.6.

cc: @mariamhas @jonahwilliams

Sidenote

We can currently only build apps on master channel due to issue #79195, that as far as we know so far only has a fix on master, so building on any other channel than master, in order to avoid this new breaking feature, is currently not an option.

Flutter doctor

``` > flutter doctor -v

[√] Flutter (Channel master, 2.3.0-1.0.pre.226, on Microsoft Windows [Version 10.0.19041.928], locale en-US)
• Flutter version 2.3.0-1.0.pre.226 at C:\Users\mryds\fvm\versions\master
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision 51ca131 (10 hours ago), 2021-05-03 19:54:04 -0700
• Engine revision 378e4db
• Dart version 2.14.0 (build 2.14.0-48.0.dev)

[√] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
• Android SDK at C:\Users\mryds\AppData\Local\Android\sdk
• Platform android-30, build-tools 30.0.3
• Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
• Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)
• All Android licenses accepted.

[√] Chrome - develop for the web
• Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Community 2019 16.9.3)
• Visual Studio at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
• Visual Studio Community 2019 version 16.9.31129.286
• Windows 10 SDK version 10.0.19041.0

[√] Android Studio (version 4.1.0)
• Android Studio at C:\Program Files\Android\Android Studio
• Flutter plugin can be installed from:
https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)

[√] IntelliJ IDEA Community Edition (version 2021.1)
• IntelliJ at C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2018.3.1
• Flutter plugin version 56.0.5
• Dart plugin version 211.7233

[√] VS Code (version 1.55.0)
• VS Code at C:\Users\mryds\AppData\Local\Programs\Microsoft VS Code
• Flutter extension version 3.21.0

[√] Connected device (5 available)
• Nexus 7 (mobile) • 0a99f5e8 • android-arm • Android 6.0.1 (API 23)
• SM T510 (mobile) • R52N906MLAV • android-arm • Android 10 (API 29)
• Windows (desktop) • windows • windows-x64 • Microsoft Windows [Version 10.0.19041.928]
• Chrome (web) • chrome • web-javascript • Google Chrome 90.0.4430.93
• Edge (web) • edge • web-javascript • Microsoft Edge 90.0.818.51

• No issues found!


</details>

However, for the past +2 years this has not been the default behavior in Flutter desktop and web applications, thus creating a de-facto default expected behavior, that users have even gotten used to

Users should not have gotten used to anything in desktop Flutter applications over the last two years. As it still says in the desktop documentation:

We don’t recommend releasing a desktop application until desktop support is stable

It would make no sense for scroll behavior on desktop to be wrong by default forever because some people ignored the guidance that desktop applications built with the pre-release versions of Flutter shouldn't be released to end users.

@stuartmorgan

@stuartmorgan that is certainly a viewpoint too. You would then prefer that we, and others that use Flutter desktop should not have used Flutter at all for the past 2 years? I think it is much better and more productive to use it despite it not being quite ready, so we can move forward, provide feedback while doing so, rather than wait until it is deemed 100% complete, which might be a while still. We thought so already 2 years ago, when we still had to install the embedders/runners manually.

All that is needed for this particular case, and probably many more that will follow, is to make the new behavior opt-in, so that past desktop and web apps do not break. The changed default behavior also affects web desktop apps. 💙 😃

Like Stuart says, the current behavior is wrong and needs to be corrected. There is simply no point in supporting desktop target platform for Flutter if we're not going to support desktop interactive standards. The old behavior was unnatural, uncanny, and made it impossible to select text in lists/scrollables! (Not to mention our general issues with selectable text, which also needs to be fixed)

If you want to opt back into the old behavior (which I strongly discourage because it will make using your app harder), you can configure the scroll behavior of your app to accept mouse drags: https://github.com/flutter/flutter/pull/81569/files#diff-0a9866e7801b58e1846f8b24d69faf9204d14f8262bf79d85e5eb3949105a19eR22

You would then prefer that we, and others that use Flutter desktop should not have used Flutter at all for the past 2 years? I think it is much better and more productive to use it despite it not being quite ready, so we can move forward, provide feedback while doing so

Using it, building things with it, and providing feedback, are not the same thing as shipping products to end users.

rather than wait until it is deemed 100% complete

Stable release and 100% complete are not the same thing.

All that is needed for this particular case, and probably many more that will follow, is to make the new behavior opt-in, so that past desktop and web apps do not break.

But you want that applied based on criteria that you have decided unilaterally, supported by a user-based argument that is based on you having ignored explicit guidance from the project.

The changed default behavior also affects web desktop apps. 💙 😃

You want the same change made in two configurations: desktop and web. I'm only addressing the desktop aspect; I'll leave it to others to comment on web.

We thought so already 2 years ago, when we still had to install the embedders/runners manually.

(Also, I would encourage you to consider how painful your app setup would be if every behavior-changing fix or improvement that has been made to desktop support since the initial FDE work required you to opt in. E.g., would you like every desktop app you create to have to turn on scroll wheel support? The earliest versions of FDE didn't support it. How about text input? Hasn't always worked. Unicode support in text input? Fixing that changed behavior.)

@jonahwilliams

@jonahwilliams thanks for the pointers 👍🏻 , a concrete example/doc on how/where to use the new APIs, to put things back to how they where before this breaking change was introduced, would have been helpful and useful, but I guess we will just dig around and experiment, but no worries, I'll figure it out eventually... 😄

When we use the API to revert some of the new behavior, it also means we are stuck on whatever channel the new API for it has reached. Currently we are stuck on master anyway due to #79195, so it does not matter so much, expecting its roll down to other channels to take a while too, so we can work with that.

Not all of the past mouse drag/swipes were bad, but yes text selection was a problem, sometimes, I don't disagree on that. On a tall 4k screen being able to mouse swipe tab pages left/right at the bottom the page instead of moving the cursor all way to the top to reach the top tabs, was actually much appreciated. This is one of the past default features that we at least want to re-enable.

There seems to be other related issues from this new breaking behavior change too, eg:
https://twitter.com/gerryhigh/status/1389566359437287424

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

"Reject mouse drags by default in scrollable", breaks apps past behavior #81832