1274086 - window.scroll parameters >2147483647 are converted to 0

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Terrell Kelley]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160512003946

Steps to reproduce:

1. Open any page with an overflow, e.g. en.wikipedia.org
2. Scroll down a bit.
3. Open the JavaScript console, and type "window.scroll(0, Number.MAX_SAFE_INT)



Actual results:

Page is scrolled back to the top, as if I entered window.scroll(0,0)


Expected results:

Page should be scrolled to the bottom, as if I entered window.scroll(0,scrollMaxY)


Additional Information:

This holds for any Number larger than 2147483647, i.e., any number that is larger than a 32-bit int. However, the spec specifically says that window.scroll takes a double. (https://drafts.csswg.org/cssom-view/#dom-scrolltooptions-left), and anything greater than the max number is supposed to go to the max (https://drafts.csswg.org/cssom-view/#ref-for-viewport-30).

And while that is technically a draft spec, it is the one cited on the Mozilla page (https://developer.mozilla.org/en-US/docs/Web/API/Window/scroll) for this function. And it just makes sense--the function should work with any valid Number value, and you already use the maximum for large values <= 2147483647.

I also note that Chrome(ium) works per spec, so this could be parity-Chrome. And I just checked on IE10 (!) and it works with number > 2147483647. So it's also parity-IE. 

A workaround is just to use 2147483647 or a sufficiently large lesser value. (The Mozilla-only window.scrollMaxY [or scrollMaxX] is twice as slow in my testing, and not on a standards track.)

Note: This is NOT an e10s or APZ bug, but the work there might make this a good time to fix it.

Comment 1

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

nsGlobalWindow::ScrollTo does

7716   // Convert -Inf, Inf, and NaN to 0; otherwise, convert by C-style cast.
7717   CSSIntPoint scrollPos(mozilla::ToZeroIfNonfinite(aXScroll),
7718                         mozilla::ToZeroIfNonfinite(aYScroll));

This seems broken.

Comment 2

[:kip (Kearwood Gilbert)]

The cleaning of non-finite numbers was done to sanitize output of the smooth scroll behavior physical modelling.  Floating point Inf values should be much larger than 2147483647; however, perhaps 2147483647 is being converted to a float Inf somewhere?

Perhaps it would be more logical in nsGlobalWindow::ScrollTo to replace passed in Inf values with 2147483647 here instead of 0.

Hope this helps.

Comment 3

[Terrell Kelley]

(In reply to :kip (Kearwood Gilbert) from comment #2)
> The cleaning of non-finite numbers was done to sanitize output of the smooth
> scroll behavior physical modelling.  Floating point Inf values should be
> much larger than 2147483647; however, perhaps 2147483647 is being converted
> to a float Inf somewhere?
> 
> Perhaps it would be more logical in nsGlobalWindow::ScrollTo to replace
> passed in Inf values with 2147483647 here instead of 0.
> 
> Hope this helps.

Could this also be why, with E10s enabled, I find that click and drag with the middle mouse button freaks out when I go below the window? It starts scrolling up instead of down.

If so, this bug would affect more people than just web designers who didn't test with Firefox.

Comment 4

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.