New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Idea: match platform scrolling behavior with Flutter using HTML scrollable area #77883
Comments
Interesting Idea. In my opinion scrolling is defenetly the most annoying thing in flutter web at the moment. |
@FelixMittermeier I am going ahead and closing this as duplicate in favor of umbrella issue. If you disagree, write in comments and I'll reopen to address it. |
Well I do not think that this is related to the scrollbar itself. It is about the scrolling functionality in general so the linked issue does not fit in my opinion. |
You are right. I probably mis-read the umbrella issue. |
Thanks for the idea. It's an interesting idea. Currently the architecture of Flutter engine and framework prefers a different approach. However, this may have potential. If anything, this may be implementable using platform views as a package. |
A similar idea #64501 |
Maybe the other one is better as it adds scrolling fidelity as well as better performance, because scrolling is happening outside the main thread in most browsers. |
Hey are their any updates on this? |
We've implemented syncing of a HTML scroll area and a Flutter scroll area in an app. When scrolling a The code we have is for a very niche case, but I can confirm this is possible and does work pretty well. The scrolling feels a lot better and more "native". I'll try to separate it out into a generic POC soon. |
Okay, managed to turn this into a very early preview package. Live example: https://native-scroll.web.app Only tested on macOS with Safari and Chrome. Will probably break under lots of conditions. Almost certainly not mobile-friendly yet. But it at least works on HTML and CanvasKit renderers. |
@tomgilder Wow, thank you so much for the great work. |
Could this be implemented on other platforms? Desktop (or at least Linux when I tested it) has the same scroll behaviour as web, and Android/iOS scrolling still isn't perfect. It's much better than Web, but some people think that it's still slightly off. Edit: in fact, are there other elements that could be improved by using native stuff? For example, text input and selecting text still don't feel quite right sometimes, so having the native platform do the work there would make sense. The challenge would be doing it without breaking custom behaviour (such as custom ScrollPhysics). |
Nice work, I'm on windows, so I needed to hide the ugly system scrollbar and add the flutter one: Wrap your ListView or whatever ScrollView you are using with Add this to the header in web/index.html <style>
::-webkit-scrollbar {
display: none;
}
</style> But my drag to scroll stopped to work when I using your package, any thoughts on how to make it work again? |
Flutter Native Scroll package does work for simple use cases, and it's code is very simple! Just wanted to copy it here for easy reference as pub.dev does not have easy online code viewing. https://pub.dev/packages/native_scroll native_scroll_web.dart
native_scroll_vm.dart
|
So what is solution? If flutter has problems with Instagram browser, Telegram browser and etc. Maybe problem not in browsers? Problem is on flutter. And HTML works fine. So scroll problem it's just in core flutter scrolling mechanism? |
my workaround with same problem: css:
js:
|
Hey @NelepovDmitry, Also using a Flutter webapp inside of Telegram webapp, but the scrolling just keeps closing my webapp... -.- Would appreciate some tips :) |
Greetings @ibsbk I found the compiled code in your repositories and it works fine But unfortunately your hack doesn't work properly on my hello world code((
Could you please advise what I'm doing wrong or give me the minimal code main.dartvoid main() {
runApp(MyApp());
}
class MyApp extends StatelessWidget {
const MyApp({super.key});
@override
Widget build(BuildContext context) {
return MaterialApp(
title: 'FlutterWebApp',
themeMode: ThemeMode.dark,
darkTheme: ThemeData.dark(),
home: Scaffold(
body: ListView(
children: [
...List.generate(
30,
(index) => ListTile(
title: Text('ListTile #$index'),
),
)
],
),
),
);
}
} index.html<!-- ... -->
<script src="https://telegram.org/js/telegram-web-app.js" defer=""></script>
<script src="js.js" defer></script>
<!--hahahahah-->
<style>
body {
height: 10000vh !important;
position: static !important;
overscroll-behavior: none;
}
flt-glass-pane {
position: fixed !important;
max-width: 100vw !important;
max-height: 100vh !important;
}
</style>
<!-- ... --> js.jsfunction resize_frame(height){
console.log('height is ', height)
document.body.style.height = `${height}px`
window.Telegram.WebView.postEvent('resize_frame', false, {height: height});
}
window.scroll(0, window.document.body.scrollHeight); |
Hi @WBgLyErCMc I had same problem after update on flutter 3.16 (or 3.13). In my case it was enough replace element name in css |
@ibsbk omg, thank you very much! |
The own scrolling functionality on Flutter Web has already caused problems a few times. The biggest disadvantage of the current implementation is the fact that it just doesn't feel natural. The speed, the acceleration and the bouncing when you reach the end, for example, are for the most part very different from "real" web pages.
So yesterday in the shower, I got an idea on how to fix all these problems in one go, and I thought it might be good to have a Flutter developer take a closer look at this idea:
In the background of the Flutter web application there should be an empty and invisible real HTML element and when the user scrolls in the browser e.g. with the mouse wheel, one should scroll directly inside this element. Then you just read with Javascript using a listener on which position this HTML scrolling element is currently located and then pass this position to the Flutter Canvas Kit where this value is then passed e.g. to the position.pixels value of a ScrollController, which then actually scrolls the app.
The big advantage of this would be that the scrolling would feel exactly the same as its implementation in every browser. In this way one would not "reinvent the wheel", but simply use what already exists and what has already been successfully tested and used.
Thanks for reading. Maybe that would be something that might be realized.
The text was updated successfully, but these errors were encountered: