Hello there! 👋 This issue was introduced in Safari 15.4 and occurs on macOS and iOS. Currently, Safari 15.4 is the next version of Safari and is in "beta". You can use it on macOS by installing Safari Technology Preview 15.4. You can use it on iOS by installing iOS 15.4 Beta. Description We use the Angular CDK's virtual scroll control (https://material.angular.io/cdk/scrolling/overview ) in our application. For some reason, the virtual scroll control will no longer scroll on 15.4 although it works fine on 15.3 and previous versions. I have logged an issue with the Angular CDK here: https://github.com/angular/components/issues/24373 . Given how this broke, this may be an issue in WebKit 15.4 and not something to be fixed in the Angular CDK, but I don't know for sure. I logged an issue with the Angular CDK to at least help the maintainers and others who might begin running into this issue have some awareness as to what's going on. I will also provide a link this WebKit issue in the Angular CDK issue. Reproduction Steps to reproduce: 1. Open https://material.angular.io/cdk/scrolling/examples on Safari 15.4. - Safari 15.4 is the next version of Safari and is currently in beta. You can use it on macOS by installing Safari Technology Preview 15.4. You can use it on iOS by installing iOS 15.4 Beta. 2. When you try scrolling the examples you'll see the virtual list will not scroll at all. - When using macOS, you'll see the vertical scrollbar no longer appears. You can't scroll using a mouse scroll wheel either. - When using iOS, touch-based scrolling doesn't work. If you open the same examples on Safari 15.3 (current stable version), the lists scroll and the vertical scrollbar is present on macOS. Expected Behavior Virtual scroll lists can scroll on Safari 15.4 like they do on Safari 15.3. Actual Behavior Virtual scroll lists do not scroll on Safari 15.4. Environment (This is inferred from the StackBlitz examples provided with the examples at https://material.angular.io/cdk/scrolling/examples .) Angular: 13.0.3 CDK/Material: 13.2.0 Browser(s): Safari 15.4 Operating System (e.g. Windows, macOS, Ubuntu): macOS, iOS
I'm not seeing an edit button (sorry, this is my first time submitting a Bugzilla/WebKit issue 😅) but I wanted to add a big THANK YOU for taking the time to consider looking into this issue! Take care, Kevin
<rdar://problem/88593617>
It looks like the `contain: strict` breaks scrolling on Webkit (but not other browsers).
<rdar://problem/88593818>
Confirmed that turning off CSS Containment fixes this.
Wow--thanks for being so amazingly responsive! 😀 I know that's not some kind of guarantee of a fix but I at least sure do appreciate someone looking at this so soon! ❤️
Does the problem go away for subsets of contain: size layout paint? Maybe we can pinpoint if the problem is due to one particular kind of containment.
It doesn't reproduce in a simple testcase. Might be something about dynamic content size changes.
Created attachment 451160 [details] Reduction Test case. Scrolled content has to be position:absolute to show the bug.
My guess is that this is about layout overflow computation.
Wow! Thank you for creating a far simpler reproduction sample, Simon! 😀 I had tried to fiddle a little with some of the CSS of the Angular virtual scroll example in effort to pinpoint what contributes to the issue but was unsuccessful. 😅 I'm glad you were able to do so! Thank you!!
This must have regressed at https://trac.webkit.org/changeset/285885/webkit as this code below does not look correct: void RenderBox::addOverflowFromChild(const RenderBox* child, const LayoutSize& delta) { if (paintContainmentApplies()) return; ... paint containment should not prevent collecting scrollable overflow (only ink overflow)
Created attachment 451254 [details] Patch
This patch modifies the imported WPT tests. Please ensure that any changes on the tests (not coming from a WPT import) are exported to WPT. Please see https://trac.webkit.org/wiki/WPTExportProcess
Thank you so much for working on a fix, Rob! 😀
(In reply to Kevin from comment #16) > Thank you so much for working on a fix, Rob! 😀 No problemo! Was my mistake, so a fix was in order :)
Committed r289443 (246991@main): <https://commits.webkit.org/246991@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 451254 [details].
Is the fix included in Safari 15.4 that was just released or do we have to wait for a bug fix release?
This should be fixed in 15.4, yes.