Bug 198598
Summary: | Don't fire scroll events during rubber-banding, when the observable values of scrollLeft and scrollTop are not changing | ||
---|---|---|---|
Product: | WebKit | Reporter: | Simon Fraser (smfr) <simon.fraser> |
Component: | Scrolling | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW | ||
Severity: | Normal | CC: | augus.dupin, fred.wang, john.crim, koivisto, simon.fraser, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
See Also: |
https://bugs.webkit.org/show_bug.cgi?id=198597 https://bugs.webkit.org/show_bug.cgi?id=199691 |
Simon Fraser (smfr)
We should only fire scroll events when the observable values of scrollLeft and scrollTop change.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/51467223>
Bruno Stasse
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).
Simon Fraser (smfr)
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.
Bruno Stasse
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.