Open Bug 1142742 Opened 9 years ago Updated 2 years ago

Setting scroll position to high, yet valid, numbers resets position to 0


(Core :: XUL, defect)

36 Branch





(Reporter: dwighthouse, Unassigned)


User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36

Steps to reproduce:

1. Create container that can scroll.
2. Insert child that has a width/height large enough to cause a scrollbar to occur on the container.
3. Set either scrollTop or scrollLeft to a valid integer near MAX_SAFE_INTEGER using JS.

Reproducibility: Always, code-detectable

Actual results:

In Firefox and Safari, scrollTop/scrollLeft values become 0, incorrectly scrolling the container all the way to the top/left instead of all the way to the bottom/right.

Full explanation and issue-detection code here:

The arbitrarily high number where failures occur in both Firefox and Safari are remarkably close to each other.

Maximum scroll position detection across browsers (Mac OS 10.9.5):
Chrome 41.0.2272.89 (64-bit)
9007199254740991 (the MAX_SAFE_INTEGER)
Also, Number.MAX_VALUE is known to work for this use case in Chrome.

Opera 28.0.1750.40
9007199254740991 (the MAX_SAFE_INTEGER)

Firefox 36.0.1
8954424844091391 (52774410649600 less than MAX_SAFE_INTEGER)

Safari 7.1.3 (9537.85.12.18)
8954424844091327 (52774410649664 less than MAX_SAFE_INTEGER)

Expected results:

They should remain at the number set, and in accordance to the spec, the container would be scrolled to a position that represents the closest it can scroll to that value, the bottom/right -most part of the scrollable area.
Sorry, in the expected results, the value shouldn't stay the same exactly. After setting the value to a high number, querying the value of scrollTop/scrollLeft should become actual, newly set scroll position (which would be the maximum possible in this case).
@assigning component - can someone please take a look at this?
Component: Untriaged → XUL
Product: Firefox → Core

Due to a continuing lack of a "scrollToBottom" method (and the fact that the "scroll" algorithm already checks the max scroll value ( so having the user do it first seems like a performance issue), it would be really nice if this could be fixed. The alternative, window.scroll(0, 9999999), is inelegant and runs the (admittedly small) risk of not working if the page size grows.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.