New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 849527 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Jul 19
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

scroll event must be fired continuously with #smooth-scrolling

Reported by netmosf...@gmail.com, Jun 5 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.62 Safari/537.36

Steps to reproduce the problem:
The "scroll" event is fired before smooth scrolling's animation is finished. So the scroll offset (e.g. scrollTop) that can be read from within the "scroll" event handler is not necessarily the actual final value that will be applied at the end of the smooth scrolling animation. In other words, when the smooth scrolling is finished, chrome must fire one more "scroll" event.
Firefox has introduced "scrollend", but I don't think it's necessary so long the scroll event is fired continuously. Thank you.

What is the expected behavior?

What went wrong?
scrollTop/scrollLeft in the last fired "scroll" handler don't match the final result

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 67.0.3396.62  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version:
 
Labels: Needs-Triage-M67
Cc: krajshree@chromium.org
Labels: Triaged-ET Needs-Feedback
netmosfera@ - Thanks for filing the issue...!!

Could you please provide a sample test file/url to test the issue from TE-end.
This will help us in triaging the issue further.

Thanks...!!
I cannot reproduce the issue anymore! not that before it happened all the time... but now I'm questioning its existence :P

I wrote this script, though... basically sometimes it happened that when the user stopped scrolling, the two values in the box would not match.
The first value is the one read at the scroll event dispatch time, the second value is updated with a setinterval.


let tn1 = document.createTextNode("");
let tn2 = document.createTextNode("");
let doc = document;
let del = document.documentElement;
let log = document.createElement("div");
log.innerHTML += "<b>- scrollTop in scroll handler: </b><br>";
log.innerHTML += "<b>- scrollTop in real time: </b>";
log.style.cssText += "position:fixed;top:0;right:0;z-index:1000000000;";
log.style.cssText += "background:white;padding:20px;color:black;";
log.children[0].appendChild(tn1);
log.children[2].appendChild(tn2);
document.body.appendChild(log);
doc.addEventListener("scroll", function(){
	tn1.textContent = del.scrollTop;
});
setInterval(function(){
	tn2.textContent = del.scrollTop;
}, 1);
Project Member

Comment 4 by sheriffbot@chromium.org, Jun 5 2018

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: Needs-Feedback
As per comment #3, please let us know if the issue can be closed or not.

Thanks...!!
Components: -Blink>DOM Blink>Input
Blink>Input can be more appropriate?
Status: WontFix (was: Unconfirmed)
I don't seem to reproduce this issue either. So I'll close it for now as the reporter also mentioned in #3 that it is not reproducible. Feel free to comment here or file a new bug if you see a similar behavior.

Sign in to add a comment