scrollTop() does not always return an Integer

[michaelvk]

While researching a very troublesome issue, I discovered that scrollTop() does not always return an Integer.

We were unable to replicate the issue, but believe it comes from some combination of the Articulate HTML5 viewer and some browser, or possibly from a PDF viewer embedded in an iFrame in an unnamed browser.

What we did see is that we had hundreds of errors where a value being posted directly to our server from the scrollTop() method that expected to receive an int value was receiving a float instead. We were able to nail down the issue by substituting a float for the scrollTop() value and seeing the exact same behavior in our server side code. When we replaced the scrollTop() value with Math.round(scrollTop value) the issue went away.

It is possible that the bug is actually in scrollTop(), not in the docs.

We are using jQuery.min, version 1.11.0, and did not see this error before we upgraded to jQuery 1.11.

[dmethvin]

We'd need a test case to be able to reproduce it. If other browser plugins OR jQuery plugins are always involved when it happens it's possible they are changing the functionality in some way to interfere with the return values.

If browsers do return a non-integer value for this in some cases, the most likely thing we'd do is just change the .scrollTop documentation to reflect that, since we are just returning what the browser tells us.

Can you provide a test case? Something at jsbin.com or jsfiddle.net would be best.

[dmethvin]

Also, is it just "some browser" or is it a particular one? Does your error telemetry have the user agent recorded?

[michaelvk]

Arrgh! Your update somehow caused Github to chuck my drafted reply, which went into detail. Let me try again.

We were never able to replicate the issue with our own testing. However, we saw this issue happening up to 1000 times per day. We service 200,000 students and about 2 million requests through the DWR library, and what we saw was that DWR was running into marshaling errors when it was receiving a floating point value (truncated to 4 precision points, e.g. 10.3636) from an unspecified call. There was no way for DWR to tell us where specifically the call was originating from, but we were able to narrow it to a handful of possibilities in our client code. In these places, DWR is being supplied values directly from jQuery or Javascript calls (these values were not typed in the client, of course).

Ultimately, replacing the scrollTop value supplied to a specific DWR call with a float replicated the behaviors, and wrapping the scrollTop value with Math.round() completely eliminated the issue.

The issue is not DWR- DWR was simply trying to marshal what it received from a POST, and throwing a low-level exception that did not reach our code, so we couldn't easily ascertain the source.

Our users tend not to be very tech savvy or up-to-date, so it could be coming from any combination of browser and platform. We serve content to them in an iFrame, and that iFrame can serve PDF, Flash, HTML5, or any other type of content depending on what our course developers use. The scrollTop value was being read out of the iFrame.

Believe me, I know it's frustrating not having a test case where you can actually make this happen. It is theoretically possible it was coming from older, unsupported browsers. Regardless, we expected to receive an Integer from scrollTop and clearly that wasn't always happening. But it was so pervasive and devastating to our clients that seeing the fix immediately solve the problems gives us a 99.9% certainty that the issue was scrollTop not always returning an Integer.

[michaelvk]

In researching the issue, the only source I found of someone reporting something similar was this:
http://stackoverflow.com/questions/17407501/jquery-scrolltop-animation-issue

[dmethvin]

Well here's the answer: Intent to Implement and Ship: Subpixel precision for clientWidth, offsetWidth, scrollTop et al

So it looks like we should update the return type of this method to be Number.

[gnarf]

Yeah - subpixels on hidpi resolutions (try chrome on a retina mac)

On Wed, Dec 10, 2014 at 3:16 PM, Dave Methvin notifications@github.com
wrote:

Well here's the answer: Intent to Implement and Ship: Subpixel precision
for clientWidth, offsetWidth, scrollTop et al
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/_Q7A4AQBFKY

So it looks like we should update the return type of this method to be
Number.

—
Reply to this email directly or view it on GitHub
#608 (comment)
.

[mikesherov]

@dmethvin can you respond to my response on the blink thread? I want / need some ammo to get this reverted in the spec / blink.

[AurelioDeRosa]

Is this a valid issue? I'd really like to clean up a bit our issues list by closing old/irrelevant issues.

[dmethvin]

We didn't change any jQuery code, it's just that with subpixel resolution on some browsers it's possible for this to not be an integer. I think the action here would be to change the documented return value of .scrollTop() from Integer to Number.

[zcorpan]

FYI returning non-integer for scrollTop is according to the current spec, and since this has been shipping successfully it is unlikely to be reverted at this point.

https://drafts.csswg.org/cssom-view/#extension-to-the-element-interface