The document's scroll event not fired when you perform a 'append'->'calculate height(or something else)'->'remove' operation, only if the scrollbar is dragged to bottom.

This bug can be reproduced with chrome/61,62,63,64, but chrome 53 and 58 are OK, the other versions are not tested.

@Reporter: Please provide sample URL/test file to test this issue from TE end. This would help in further triaging of the issue.

Thanks!

Ping still waiting on repro URI. Please provide.

Here is a demo, please check it, Many thanks.

Deleted: scroll-event-fired.1.html 1.8 KB

scroll-event-fired.1.html 1.8 KB View Download

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Is this a known bug?

Many thanks to Sheriffbot. :)

You are getting a scroll event per layout lifecycle. Since you are forcing a layout (via querying height/width) this will dispatch the scroll event for that phase.

You are getting a scroll update for the append (adding a node to the document causes the scroll position to be adjusted (because the document size is increasing) and a scroll update for the remove (because the document size is decreasing).

bokan@ can correct me if I am wrong.

Actually, I'm not sure about that. If you're fully scrolled, adding an element should increase the amount of scrollable content, but it shouldn't change the scroll offset.

If I change the append and remove to happen from separate buttons and manually append and remove, the scroll offset never changes and no events are fired - as I'd expect. I'll take a closer look to see what's happening.

This is a small bug in scroll anchoring. What's happening is that when we first scroll to the bottom, we set an anchor on the green box just above the buttons and it's saved relative offset as you currently see it (i.e. y is likely negative since the box's top is above the viewport).

When we remove the bottom box, we don't update the saved_relative_offset_ in the ScrollAnchor. Then, when we add a new box below (without scrolling) the ScrollAnchor activates, attempting to keep the box above at the original negative y (though it's changed since then). The real bug here is that appending a box after removing the first one erroneously scrolls down. I've slightly modified the reporter's repro to show this: https://bokand.github.io/bugs/anchor.html

It seems like clamping scrolls should cause the scroll anchor to recompute the saved_relative_offset_. Over to skobes@ to determine if this is know and how important this is to fix.

comment 13 seems t0 be correct.  Also happens on current Kevin stable channel. 

for example something similar happens in the chrome interface settings pages.  
1. Open settings
2. Navigate to Advanced section.
3. Tap or click on content settings 
4. Tap or click on Cookies 
5. Tap or click on Cookies and Site Settings 
6. Scroll down so that the top of the page is no longer in view.
7. Click the garbage can next to the individual cookie or setting
8. The scroll bar reverts to the top of the page, losing the place of the viewer where they are.  

this same issue happens when a series of check boxes or option boxes are visible and interacted with on many web pages.  For example, I edit on Waze.  Since this interface change, each time a user selects a checkbox to add a feature to a new place being added into the map, the scroll resets to the top making the user have to scroll and find where they left off again to continue.  It has actually caused a few editing errors that create double work in many cases and result in users missing edit points.  This seems to happen most often when there are multiple scroll boxes outside of the main one on the right of the large page when it comes to Waze.  As if internal elements are not properly saving scroll orientation but instead what you get is what is seem in comment 13.  That is my theory.