[web] Scroll is not recognized by the browser

Steps to Reproduce

Flutter is painted on a canvas and the browser doesn't detect the scroll.

This causes problems when the native browser uses the scroll to perform their own actions.

Current problems:

Safari and Chrome iOS/Android address and bottom bar navigation doesn't collapse when scrolling:
Issues: [web] Allow Flutter apps to have 13% bigger screen after being scrolled down #64572 Flutter for Web does not hide url bar and navigation bar on scroll in iOS's Safari #68877

Current behavior	Expected behavior (would also need to scroll)

iOS scroll to top by tapping on the status bar doesn't work. A feature available for any website in any ios browser or WKWebView
iOS GoogleMaps, Google Assistant, Facebook & Facebook Messenger displays in-app websites inside a draggable modal. Because of scroll is not detected, the modal is closed instead of scrolling upwards.

Issue reproducible on latest master channel.

flutter doctor -v

[✓] Flutter (Channel master, 1.24.0-7.0.pre.47, on Mac OS X 10.15.7 19H2 darwin-x64, locale en)
    • Flutter version 1.24.0-7.0.pre.47 at /Users/pedromassango/dev/SDKs/flutter_master
    • Framework revision 2f18e0b23d (20 hours ago), 2020-11-01 20:58:04 +0530
    • Engine revision 3460519398
    • Dart version 2.12.0 (build 2.12.0-3.0.dev)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.1)
    • Android SDK at /Users/pedromassango/Library/Android/sdk
    • Platform android-30, build-tools 30.0.1
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.1, Build version 12A7403
    • CocoaPods version 1.9.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    • 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-b3-6222593)

[✓] IntelliJ IDEA Community Edition (version 2020.2.3)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    • Flutter plugin version 50.0
    • Dart plugin version 202.7319.5

[✓] VS Code (version 1.50.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.16.0

[✓] Connected device (4 available)
    • iPhone 12 Pro Max (mobile) • ECCF5C4A-8BEC-411D-B23E-85A836C3847E • ios            • com.apple.CoreSimulator.SimRuntime.iOS-14-1 (simulator)
    • macOS (desktop)            • macos                                • darwin-x64     • Mac OS X 10.15.7 19H2 darwin-x64
    • Web Server (web)           • web-server                           • web-javascript • Flutter Tools
    • Chrome (web)               • chrome                               • web-javascript • Google Chrome 86.0.4240.111

• No issues found!

I thought we had a duplicate issue for this, but I failed to find one. I'm accepting this as a feature request.

I've been thinking about some ideas for fixing this. Leaving this idea before I forget: the web engine could use a signal from the framework that there's a scrollable area that the user is interacting with as well as when the start/end has been reached. We could then make the body element (or some other top-level element) scrollable while keeping the Flutter View in a fixed position. The browser will see the element scrolling and react appropriately.

@jamesblasco

@jamesblasco Curious how did you get it to behave correctly in the "Expected behavior" screen recording?

@mncorreia

@mncorreia it doesn't work on chrome/android

I don't understand your gif because just worked, alright?! hahaha

@mncorreia no it doesn't
this is how is supposed to work, focus on chrome's address bar

I don't want to nitpick,
I just want to avoid this issue to be slapped with label:"workaround available"
and forgot forever (like many other web issues)

Okay, this thread is getting a little hard to follow recently.

Is there a workaround that we can add to an app that enables the behavior of the app bars to hide when a Flutter view is being scrolled? How exactly would someone implement this workaround?

@huycozy

Okay, this thread is getting a little hard to follow recently.

Is there a workaround that we can add to an app that enables the behavior of the app bars to hide when a Flutter view is being scrolled? How exactly would someone implement this workaround?

the point is (and always has been afaik) that the browser doesn't detect the scrolling
therefore doesn't hide/reveal the address bar (see original post)
what worries me is

contributors announcing non-existing workaround
creating the risk that maintainers may accidentally flag the issue with label:"workaround available"
decreasing the priority of the issue
this issue was supposed to be blocked by #139263 but even if that one has been solved
this issue doesn't seem to be actively worked on

cc @huycozy @yjbanov

None of the above workarounds (gambiarras) have worked for me as of today's date. I'm in the middle of developing an app that uses Flutter to display high-quality images and videos. I was excited to show it in full screen on mobile devices, but now I'm really frustrated by how long this issue has been open without being addressed. I guess I'll simply use React or another tool that already has this feature easily implemented. This is a HUGE problem in today's modern visual web applications.

Flutter mobile web hasn’t been getting much (or any?) love for a long time. this is just one of a few bigger issues which I experienced over past years. and its really strange to me that it is like that considering most of web traffic, in general, goes over mobile.

Yes, this issue is a frustrating one. But also no: Flutter web has been getting love. They have worked on getting the wasm standards developed to support garbage collection to work better with Dart and Flutter (talk about long-term thinking!), they have implemented building separate framework bundles for different browsers to minimize download times, they've introduced new JS interop features, and I'm sure there's much more (maybe there's a web roadmap somewhere?). My 2 cents are: let's keep these GitHub issues focused on the technical issues (and solutions), let's put thumbs up on the issues we really want to see solved, and let's try to contribute and figure out fixes as best we can.

I created a proof-of-concept PR that addresses this for iOS and Android: #184281

It switches touch input handling from Pointer Events to Touch Events, which allows touch-action: pan-y without breaking gestures. The approach is minimal — pointer_binding.dart is unchanged.

Feedback on the approach is welcome.

Thanks for the PoC!

Any news on a potential fix being merged? 👀

Follow-up on #184281: it has been closed, and the reasons are in the PR.

With engine changes in Flutter 3.50, the same approach now works as a package, with no further engine changes. It is published as a new package.

https://pub.dev/packages/web_address_bar

It needs Flutter 3.50 or later, which is on the beta channel as of today.

void main() {
  WebAddressBar.enable();
  runApp(const MyApp());
}

It covers the address bar collapsing and, with WebAddressBarScrollToTop, scrolling to the top on an iOS status bar tap.

Feedback is welcome.

Navigation Menu

Repository navigation

[web] Scroll is not recognized by the browser #69529

Steps to Reproduce

141 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[web] Scroll is not recognized by the browser #69529

Description

Steps to Reproduce

Activity

pedromassangocode commented on Nov 2, 2020

yjbanov commented on Dec 4, 2020

yjbanov commented on Dec 4, 2020

yjbanov commented on Dec 4, 2020

141 remaining items

iapicca commented on Oct 5, 2024

QoLTech commented on Oct 7, 2024

iapicca commented on Oct 8, 2024

jongseokleedev commented on Nov 1, 2024

gusflrnd commented on Feb 27, 2025

fralways commented on Feb 28, 2025

olof-dev commented on Mar 1, 2025

koji-1009 commented on Mar 28, 2026

flt-phy commented on May 6, 2026

koji-1009 commented on Oct 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions