This bug is the cousin of bug 62536. The purpose here is to implement document.documentElement.clientWidth/clientHeight DHTML properties within Moz exactly the way it works within MSIE 6 in standards compliant mode. Solving this bug, I feel, would eliminate all the problems and frustations related to precise and accurate layout of web sites where knowing exactly the dimensions of the client area (also known, referred as content area) and the dimensions of the browser viewport are decisive. I believe bug 140308 and bug 48634 as re-summarized (and maybe bug 72540, bug 76197) to be very much related to the implementation of document.documentElement.clientHeight/Width. People in bug 140308 and bug 48634 want the window.innerWidth and window.innerHeight properties to "behave" like MSIE's document.documentElement.clientWidth/Height properties. Right now, the latest nightly build of Mozilla returns 0 for these properties. A test case follows.

** You must use MSIE 6 in order to view this test case ** There is no other way to illustrate how MSIE 6 renders these properties in "CSS1Compat" mode. Instructions: Using a high video screen resolution is better, preferable. The moving lines (red, blue, purple ones) purpose is to illustrate how absolutely positioned elements when positioned outside the client area cause the root element to be streched, cause the dimensions of the root elements to be increased and cause the appearance of scrollbars. (Another specific test case might be needed to better achieve this.) Absolutely positioned elements are taken out of normal flow and are positioned outside the body element in the html element. One final note: MSIE 6 does not render margins for the html element, does not display margins for the html element but Mozilla-based browsers do.

Additional comments on the test case. Move the mouse to the far right, beyond the lime border and/or move the mouse to the bottom beyond the lime border. This will create scrollbars and the values of document.documentElement.clientWidth/Height will be updated in real time. This is the behavior that many people "expect" or demand (bug 140308, bug 48634) from window.innerHeight/Width properties. Window.innerHeight/Width are totally different properties measuring something else.

To the right component.

That this does not work really amazes me. Why is it that clientWidth works for any element but the root element? Is it possible that the root element has a different type of ScrollView than other scrollable elements? Most likely yes, and since clientWidth uses the scrollView.clipView.bounds something is going wrong here. (Sorry I could not get that deep into the code to actually find the problem but I think I at least got a bit closer to finding the reason for the bug.)

"Is it possible that the root element has a different type of ScrollView" It is possible that I don't know what this means, but I'll make a stab in the dark. HTML{ overflow: auto; } causes scrollbars to disappear. Does this mean anything? If you try it with javascript on a loaded document, scrollbars remain but disappear. Try it: javascript:void(document.documentElement.style.overflow='auto'); Is there a dependency? I think this may be related to bug 54661

Re comment #4 and #5: Try the following page with MSIE 6 for windows, Mozilla, etc... and you'll see differences (but these values are constant for each browser and each rendering mode) in the margins applied to the body, to the overflow (and overflow-y) values of both the body and html elements, even a default border on the html element for MSIE 6, etc.etc. I just added css width and css height a few min. ago. http://www.geocities.com/Area51/Realm/8655/HTMLJavascriptCSS/BrowsersDefaultValues.html Also, please try the attachment 90581 [details] in this bugfile if you have MSIE 6 for windows: I think it is revealing, empirically demonstrating some of the hidden default browser values of the html and body elements.

clientHeight Property Internet Development Index Retrieves the height of the object including padding, but not including margin, border, or scroll bar. --------------------------- documentElement.clientHeight may be higher than window.innerHeight. documentElement.clientHeight may be lower than window.innerHeight. 1) documentElement.clientHeight will be higher than window.innerHeight when the html element has height: auto. What you really want is the offsetHeight of the ICB, which is really window.innerHeight - vScrollbarWidth. 2) documentElement.clientHeight will be lower than window.innerHeight when the html element has borders. 3) documentElement.clientHeight will be lower than window.innerHeight when the html element has a height property that is less than the window's innerHeight. In statement 1, the initial containing block has the scrollbar. the height of the html element is unchanged. it may be higher than the ICB containing it. The ICB has a default scrolling mechanism that is provided automatically by the browser. In statement 2, borders are not included in the clientHeight property. If the offsetHeight of the root (html) has borders, it's clientHeight must be less than the innerWidth. In statement 3, If the offsetHeight of the root (html) is less than the height of the viewport, then the clientHeight property will be less than window.innerWidth. There currently is a bug in mozilla, bug 15405, that prevents html from being less than the viewport's height, so statement 3 can't be tested until that bug is first fixed (dependancy).

Mass-reassigning bugs to dom_bugs@netscape.com

From the Description above: >The purpose here is to implement >document.documentElement.clientWidth/clientHeight DHTML properties within Moz >exactly the way it works within MSIE 6 in standards compliant mode. I'm afraid that is an impossible goal, see bug 227567 comment 8 and 5. With the patch in bug 227567, in "Testcase #2", I get diff: 10,10,15,25,25 which is very close to what I get in IE: 10,10,16,26,26 (the IE scrollbar seems to be 1px wider). I think the patch in bug 227567 fixes the problems in this bug (it is very close to what IE does) - or is there something I missed?

In the testcase #2, I assume that these are divs all bordered with a 5px solid border. But still, this bug is about the root (documentElement) element. I created a simple testpage where the <body> node is entirely empty and I was still able to get MSIE 6 to output the client area (or rendered area) dimensions (clientWidth and clientHeight). I fail to see the problem. I have many testcase pages; if I understood exactly what is the situation, I might be able to help. You note a 1px difference in the scrollbars. FWIW, one can modify the width/height of the vertical/horizontal scrollbar in XP for browsers like MSIE 6 and Opera 7 with Start/Settings/Control Panel/Display/Appearance tab/Advanced button/Item:Scrollbar and such measurements may vary from Windows theme to theme also. FWIW, MSIE 6 has a default CSS border declaration on the <html> node which is medium #000000 inset which explains the difference between clientHeight and offsetHeight... which might be mysterious. I understand that the root element is directly associated with the browser viewport in MSIE 6 when this is not the case (nor the default) in Mozilla. In any case, Mats, as soon as the fix to bug 227567 is in the trunk, I'll be happy to run tests for this bug. From the values you get with testcase #2, I have a hunch that your patch should solve the issues with this bug.

Please file new bugs for any remaining problems (*one issue* per bug report), including a minimized testcase, thanks. -> FIXED (by bug 227567)

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

Followings code works for me in IE6, FF3.5.3, Chrome5.0.375.127, and I think it summarizes the issues well. Felt it was important to post here, since similar new and reopened bugs are marked duplicates of this resolved bug. function docElem( property ) { var t return ((t = document.documentElement) || (t = document.body.parentNode)) && Util.isNumber( t[property] ) ? t : document.body } // View width and height excluding any visible scrollbars // http://www.highdots.com/forums/javascript/faq-topic-how-do-i-296669.html // 1) document.client[Width|Height] always reliable when available, including Safari2 // 2) document.documentElement.client[Width|Height] reliable in standards mode DOCTYPE, except for Safari2, Opera<9.5 // 3) document.body.client[Width|Height] is gives correct result when #2 does not, except for Safari2 // 4) When document.documentElement.client[Width|Height] is unreliable, it will be size of <html> element either greater or less than desired view size // https://bugzilla.mozilla.org/show_bug.cgi?id=156388#c7 // 5) When document.body.client[Width|Height] is unreliable, it will be size of <body> element less than desired view size function viewSize() { // This algorithm avoids creating test page to determine if document.documentElement.client[Width|Height] is greater then view size, // will succeed where such test page wouldn't detect dynamic unreliability, // and will only fail in the case the right or bottom edge is within the width of a scrollbar from edge of the viewport that has visible scrollbar(s). var doc = DocElem( 'clientWidth' ), body = document.body, w, h return Util.isNumber( document.clientWidth ) ? { w : document.clientWidth, h : document.clientHeight } : doc === body || (w = Math.max( doc.clientWidth, body.clientWidth )) > self.innerWidth || (h = Math.max( doc.clientHeight, body.clientHeight )) > self.innerHeight ? { w : body.clientWidth, h : body.clientHeight } : { w : w, h : h } }