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
fix(iOS): setting correct default DecelerationRate for iOS to normal #2815
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Types fix makes sense, and looks like that should also be fixed in the documentation? (the Reference.md files)
@Titozzz This "fix" makes sense, but thoughts on dealing with the "breaking change" aspect (changing the default, thus likely leading to different scrolling behavior for existing apps)? Would something like this justify a major version bump? |
Can this be merged @Titozzz ? |
It does and when I merge it, it will mark as breaking @ftlno I've been hard working on the new arch pr but hopelly u can go through all open PRs soon 😉 |
Hello 👋, this PR has been opened for more than 2 months with no activity on it. If you think this is a mistake please comment and ping a maintainer to get this merged ASAP! Thanks for contributing! You have 7 days until this gets closed automatically |
It would still be great to see this merged |
Hello, after going through as many stack overflow and apple threads I could: From my understanding, WebView, even if it's using a scrollview has it's own default. See (https://stackoverflow.com/questions/14763255/why-does-scrolling-a-uiwebview-feel-so-much-different-than-scrolling-any-other#comment25190463_14763634) Understanding this, I'm not sure that change make sense as the idea is to stick to native behavior as much as possible. Also users are free to set decelerationRate to normal if they want to. What we could probably improve is the documentation, explaining this. WDYT? |
@Titozzz The thing is, right now we're not really using the WebView default I don't think. The code is explicitly setting the deceleration rate to an uninitialized float (which maybe is treated the same as if we didn't set it at all? but I wouldn't bet on that..). Point is valid though that maybe it's worth checking what the default value really is for the webview, in case it's different from a standalone scrollview (and update the documentation either way). |
It was my expectation that a standard web wrapper app such as this
would exactly match the scroll behaviour in the safari or chrome iOS apps. The fact it didn't felt janky and to me it's a hard fix to find that the I made a similar starter app in SwiftUI using the same underlying WebView component and the scroll behaviour matches safari/chrome apps by default I'd suggest merging this PR or a similar fix and introducing a major version bump to account for users which expect the current scroll behaviour as default 😁 unless there's something I'm missing here! happy to share code for the swift ui demo too |
React native WebView should match whatever the default of WebView is when building a native app with ObjC/Swift. Someone should create a test app to find out the default even though I expect it will be "deceleration: fast" |
It's set to 0.998 which corresponds to normal Here's the logs and code from inside a swift app
|
"Fast" decelerates too fast compared to Safari. We had to override to "normal" in our app to get the expected scroll desceleration behaviour Edit: Also Apple's documentation on UIScrollView.DecelerationRate and decelerationRate
|
Has anybody tried just commenting out react-native-webview/apple/RNCWebViewImpl.m Line 909 in 891e595
(I'm not ignoring the science @ewan-m already did above, I'm just curious to further double-check the "default" value in the context of |
that's a good suggestion quite curious too - but is there anything else to do to help getting this in? |
It seemed to me like the main blocker was disagreement/confusion over what the correct default behavior would be. My suggestion was intended to help resolve that debate. |
https://github.com/ewan-m/webview-scroll-speeds Here's a repo with basic webview apps built in both Expo and Swift. Running on an iOS device you can noticeably feel the difference in scrolling behaviour. The Swift app prints out the defaults too. These defaults should be the same in both apps as they are both using the same underlying WebKit Webview
In order to make the Expo app match the Swift app you need to add Funnily enough if you're using Apple Silicon (M1/M2) you can't notice the bug at all because there's a bug in the scroll behaviour of V14 Simulator itself https://developer.apple.com/forums/thread/668488 - I imagine this is where a lot of confusion must comes from! Would you like a screen recording of both apps in my phone with examples of what changing the deceleration rate prop does? Appreciate the diligence btw in double checking we're doing the right thing! https://github.com/ewan-m/react-native-webview here's a fork with your suggestion as well and confirms the same thing |
I'm looking forward to seeing this getting merged. It seems like a anti pattern to make every developer writing webviews to understand that they should change this to normal to get the correct default behaviour. And understand that it breaks the UX of those who are used to using the wrong default, but its way better for future apps and developers to getting the right default. |
Is there anything else we can do to get this merged? |
Hello 👋, this PR has been opened for more than 2 months with no activity on it. If you think this is a mistake please comment and ping a maintainer to get this merged ASAP! Thanks for contributing! You have 7 days until this gets closed automatically |
@Titozzz @TheAlmightyBob – Please consider merging this fix |
Hello 👋, this PR has been opened for more than 2 months with no activity on it. If you think this is a mistake please comment and ping a maintainer to get this merged ASAP! Thanks for contributing! You have 7 days until this gets closed automatically |
This is very much a bug still. Are there any reasons why you won't implement this fix, @Titozzz @TheAlmightyBob ? |
Any reason why this isnt merged? |
hello! @Titozzz @TheAlmightyBob Would be great if this would be merged. I think it contributes greatly to the perception of react native having a poor performance because a lot of people starting a migration project from a web app will be likely to begin with a Webview. They'll then notice it "seems to struggle to scroll the webpage" and think hmm maybe react native has poor performance - but that's not true! just this default is wrong 😁 |
Hello 👋, this PR has been opened for more than 2 months with no activity on it. If you think this is a mistake please comment and ping a maintainer to get this merged ASAP! Thanks for contributing! You have 7 days until this gets closed automatically |
The default is still wrong. Could we please get a response on this? @TheAlmightyBob @Titozzz |
Source: developer.apple.com
https://developer.apple.com/documentation/uikit/uiscrollview/decelerationrate