Bug 25240 – offsetHeight/scrollHeight/clientHeight values on the body and html elements don't match FF/IE in many cases

• Status: NEW
• Component: DOM

[Erik Arvidsson]

Getting the offsetHeight of the body element in a document in quirks mode returns the client height of the window. It is supposed to give the actual border-box bounding height of the element. This used to work correctly (our continuous builds started breaking with newer webkit versions).

All other browsers agree on this.

Test case coming up.

[Erik Arvidsson]

Created attachment 29541 [details]
Shows that scrollHeight is broken

Try resizing the window. The scrollHeight should not change. It should always be 200.

[Erik Arvidsson]

Correction: offsetHeight is correct. scrollHeight is the faulty property.

[Erik Arvidsson]

http://erik.eae.net/chrome/scrollheightbug.html
http://erik.eae.net/chrome/scrollheightbug-backcompat.html

My suggestion for getting this slightly more sane.

Step 1: In CSS1Compat mode, make scrollHeight/Width match IE, Gecko and Opera. They all agree and when in standards mode the body should not be treated specially.

Step 2: In BackCompat mode make documentElement.offsetHeight = documentElement.scrollHeight = documentElement.clientHeight = body.offsetHeight. This is what Gecko and Opera does. IE returns 0 for clientHeight but otherwise do the same as Gecko and Opera. This also fixes the issue where we currently see offsetHeight being smaller than clientHeight.

I got step 1 working in my client but wanted to hear other peoples input before I continue.

[Erik Arvidsson]

Created attachment 29658 [details]
Table describing how different browsers handle these properties

I got this table from Anne van Kesteren and I validated that it was correct. I then updated it with my plan how to fix WebKit.

[Erik Arvidsson]

Anne, I cc:ed you on this since I know you are working on a spec for this. My main motivation for this change is that it breaks real world applications but I'm also concerned that any change we make here will cause regressions.

One thing that is pretty clear is that offsetHeight >= clientHeight in all cases.

[Ojan Vafai]

Updating the summary from "REGRESSION: document.body.scrollHeight is wrong in BackCompat mode" since this is more general now.

Hyatt, mind taking a look at this table? Do the proposed changes seem correct to you?

[Erik Arvidsson]

Created attachment 29662 [details]
Updated table

[Ojan Vafai]

Related bug: https://bugs.webkit.org/show_bug.cgi?id=25314

For sanity sake, I would say we should focus this bug on figuring out the right strict mode behavior. We can deal with quirks mode later.

[Alexey Proskuryakov]

*** Bug 29117 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

Created attachment 39465 [details]
test case for bug 29117

Reduced test case for bug 29117, wrong result of HTMLElement.scrollHeight causing a site compatibility problem.

[Peter Abrahamsen]

Further, scrollHeight is available on inline elements on FF 3.6 but not in Safari or WebKit. I don't have IE handy, and didn't find an answer with a quick search so I don't know how it behaves.

[Anne van Kesteren]

*** Bug 13173 has been marked as a duplicate of this bug. ***