This project is archived and is in readonly mode.

#1087 ✓resolved
Tim Wienk

getScrollSize in Webkit browsers not correct for textareas

Reported by Tim Wienk | November 14th, 2010 @ 12:08 AM | in 1.4.0 (closed)

getScrollSize in Webkit browsers apparently does something funky with paddings.

Moved from More ticket 254.

see this simple example of an auto-expanding textarea element. working firefox, not in chrome.

This also holds true when trying trying to user getScollSize on the window object or just calling getScrollSize() itself. In particular the Y property always comes up short. Depending on the length of the page, it can be a few hundred pixels off.

here's a JS fiddle:

Comments and changes to this ticket

  • Christoph Pojer

    Christoph Pojer February 23rd, 2011 @ 12:54 PM

    • Milestone changed from 1.3.1 to 1.4.0
    • Milestone order changed from “15” to “0”

    you wanna fix it Tim? :)

  • gingebaker

    gingebaker June 8th, 2011 @ 02:49 PM

    is this fixed already? i had a similar issue with mootools and chrome/safari not getting back the correct Size when calling getScrollSize() in an domready Event. After some testing I found out that waiting some more time (i made an delay of 400ms) chrome/safari gave me the correct ScrollSizes...

    In the scrollable area I had a listing ot thumbnail images...

    This happened in chrome 11.0.696.77, and safari win 5.03.

  • gonchuki

    gonchuki June 8th, 2011 @ 06:38 PM

    As far as mt experience tells, this is a WebKit bug.

    Working on similar code (for an auto-expanding textarea) I found a very realiable fix. Basicaly the thing is that you can always find out if WebKit is returning the wrong values by doing textarea.scrollHeight - textarea.offsetHeight. The value returned from this substraction has to be substracted from the height you are applying to the textarea and will work in a cross-browser fashion. On my code, that's textarea.scrollHeight - (textarea.scrollHeight - textarea.offsetHeight).

    Not sure if this same fix applies to anything else than textareas or if it can be introduced as part of MooTools, but it's been tested to work at least on IE7+, Firefox 3.6+, Opera 11+, Safari 5 and Chrome 7 or 8+.

    @gingebaker: would you mind trying out my fix on your code so we can confirm if it works reliably for other elements? Also keep in mind that Chrome was formerly known for firing domready too early and trying to measure stuff always returned incorrect values. I'm not sure if this still holds true for latest Chrome builds, but it's another option given that you are experiencing an issue that can be solved with delayed execution of your code.

  • gingebaker

    gingebaker June 8th, 2011 @ 09:08 PM

    Hi gonchuki.
    I tried it in my scenario (in my case its scrollWidth and offsetWidth). Without delaying the domready event the scrollWidth and offsetWidth returned the same wrong value in Chrome. It returns the viewable width of the element. After delaying it again the scrollWidth has the correct size and offsetWidth stays the same.

    At the moment delaying is the only thing I can think of?
    Should i upload a test scenario where you can see my problem? However, I also think its webkit thing not a mootools...

  • Christoph Pojer

    Christoph Pojer August 13th, 2011 @ 12:20 AM

    Do we have any news on this?

  • ibolmo

    ibolmo January 19th, 2012 @ 09:55 AM

    • State changed from “open” to “resolved”

    I'm setting this as resolved. If you're still having trouble please create a Github Issue at

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Shared Ticket Bins