198598 2019-06-05 19:58:10 -0700 Don't fire scroll events during rubber-banding, when the observable values of scrollLeft and scrollTop are not changing 2021-06-07 14:11:16 -0700 1 1 1 Unclassified WebKit Scrolling WebKit Nightly Build Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=198597 https://bugs.webkit.org/show_bug.cgi?id=199691 InRadar P2 Normal --- 1 simon.fraser webkit-unassigned augus.dupin fred.wang john.crim koivisto simon.fraser webkit-bug-importer oldest_to_newest 1542278 0 simon.fraser 2019-06-05 19:58:10 -0700 We should only fire scroll events when the observable values of scrollLeft and scrollTop change. 1542280 1 webkit-bug-importer 2019-06-05 19:58:50 -0700 <rdar://problem/51467223> 1767414 2 augus.dupin 2021-06-07 05:05:01 -0700 Am I mistaken or do the observable values of scrollLeft and scrollTop do change during rubber-banding? When overscrolling at the top of a scroll container I get negative values for scrollTop for example (which seems like a good behaviour). 1767496 3 simon.fraser 2021-06-07 11:51:52 -0700 There are many websites that do the wrong thing with negative offsets (e.g. the double-translate fake-fixed elements). I don't think the negative values are web-compatible. 1767544 4 augus.dupin 2021-06-07 14:11:16 -0700 I'm not sure I see the problem this can cause, however... scroll values communicated during overscroll seem quite useful to me as they allow to implement animations like zooming a fixed picture or a title when overscrolling at the top of a page. Which wouldn't be possible without it. And knowing that we are overscrolling in a scroll event handler can be quite useful in other situations. It would really be too bad to lose this information. At least if both clamp and unclamped values could be available (as suggested here: https://bugs.webkit.org/show_bug.cgi?id=198597#c3) that would be nice.