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.
Created attachment 90581 [details] How document.documentElement.clientHeight/Width and document.documentElement.offsetHeight/Width works within MSIE 6 in standards compliant mode ** 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.
15 years ago
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.)
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 firstname.lastname@example.org
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. ***