Steps to reproduce
scrollTop property must not remove scrolling inertia.
Dev Channel specific:
Comments and activity
- Microsoft Edge Team
Changed Assigned To to “Mara P.”
Changed Assigned To to “Rob A.”
Changed Assigned To to “Christian F.”
- Microsoft Edge Team
Changed Assigned To from “Christian F.” to “IE S.”
Changed Status to “By design”
Generally speaking we intentionally halt inertia. Cases as you mention where the intention is to shift the scroll offset in tandem with content so the user never realizes a scroll occured it is better to retain inertia. However, Edge’s current behavior optimizes for other scenarios such as resetting scroll offset to 0 for a view change, scrolling a particular element into view, etc. There are pros and cons to both stopping vs. continuing the inertia, but the more common cases we’ve seen have intended the scroll offset set to represent a new and separate scrolling operation that carries no inertia.
In your specific example you’re setting the value of scrollTop to its current value, which we’ve considered special-casing to avoid interrupting the scroll. But based on your description of the scenario I think you are looking to set other values so that special casing would not apply.
I’d recommend if possible finding ways to manipulate content that don’t require alteration of the scroll offset, e.g. defer adding items until scroll completes. This can also help with user experience for other input types that don’t handle changes to scroll offset during scrolling well, e.g. clicking and dragging the scrollbar, home/end keys.
That is unfortunate but reasonable. Thanks for the tip :D
But I think that tip will be complicated as we don’t have scrollstart and scrollend event. Manually supporting this will require setting timer, which will make things complex.
And additionally, this is a real world problem and you can test the behavior on tweetdeck.twitter.com where list items are added without observing scroll event.
Agreed this would be a good scenario to improve upon perhaps with some additional eventing. We experimented with a similar event (MSManipulationStateChanged) back in IE10 to help with this situation, but it ended up being a bit awkward to use. We’ll definitely think more about how to make this pattern easier to implement.