Using latest 1.0 branch as well as trunk build on win-xp there is a problem with the value window.innerWidth is returning. A testcase is available at (see the news-scroller) http://www.world-direct.com/mozilla/dom/starter.html Things are fine if there is a scrollbar in the Mozilla window. If resized so that no scrollbar appears window.innerWidth has the wrong value (Mozilla still thinks there is one according to the value).

Markus, would you mind reducing that testcase please? Something like alert("This is window.innerWidth, please resize the window now"), then alert the new innerWidth. Thanks in advance! Moving to DOM Level 0.

I believe this is a known backwards compatibility thing with Nav4 which did not do it correctly either. We are emulating Nav4's bugs on this. I would prefer to fix it but it was determined earlier that Nav4 compat was more important...

self.innerWidth; which is necessary for NS4 is working correctly! When there is a scrollbar the value is reduced by the number of the scrollbar width. Not so in Mozilla! Just take a look at the testcase again - now with an alert box saying the window.innerWidth. Resize just horizontally so that you have the Mozilla window either with a scrollbar and without one. You will see that the value in the alert box remains the same.

Basically, it appears that as of mozilla 1.0 RC3 that BOTH innerHeight and innerWidth are ignoring the scrollbars. I have verified this on win2k as well, and am uploading a small example which clearly illustrates this. Details of the example: 1) css (creates a border around a div for illustration sake) 2) javascript function a) determines innerWidth and innerHeight b) selects the sytle element of the div by id c) changes top/left/width/height of the style d) this "should" create a box 10px from each edge e) alert with ('innerH x innerW' dim 'resizedH x resizedW') 3) html a) onload / onresize / onreload calls #2 b) div containing breaks and -'s to cause scroll bars to appear Notice when window is large enough for the content the div "box" appears correctly. Note that the dims returned by the alert are exaclty 20px different. Now load with scrollbars in place and notice the whole box is not visible. Yet the dims are correctly again 20px different than the inner values returned. Also I should note that it appears the content is loaded and the javascript function appears to be called BEFORE mozilla applies the scrollbars to the page. So basically it appears that the script is being called before the content display area has been determined (at least in regard to scrollbars) by mozilla.

thx for the great testcase

So what does that testcase demonstrate? That if the innerWidth is measured before the scrollbars have appeared it does not account for the scrollbars? That seems obvious... What am I missing?

dupe of bug 131029 ?

Basically what is shown by the test case is that it either Mozilla is calling onload / onresize / onreload BEFORE it is finished rendering the page -- or -- Mozilla has dropped window.innerHeight() from the list of fuctions it supports. Looking at the dup bug Clary listed, this may be the same issue, however I would like to note that NS versions do use this property... And unless you guys have added the IE method mentioned... since last I tried it (before 1.0 I will admit), the funtion mentioned in the other bug did not work. Anyways, if anyone from Mozilla Dev takes another look in here, I have a simply question: Why not just standardize using body.sytle to store the width and height? maybe it is just me but that makes far more sense than having client specific ways to get the style properties for the body of a web page - not to mention I believe it would fit well with the current w3c specifications and emcascript specifications.

OK.... What that testcase needs is a clear explanation of what the expected output is and how the actual output differs from the expected output.... > Why not just standardize using body.sytle [sic] Because body.style is already standardized -- this is the CSSDeclaration corresponding to the inline style on the body.

Several weeks ago, Martin Honnen and I underlined to Markus that window.innerWidth/Height always include scrollbars (if present). Document.body.clientWidth/Height does address accordingly and conveniently the question posed by the bug. Window.innerWidth/Height = dimensions of the browser's viewport. Document.body.clientWidth/Height = dimensions of the client area, content area without scrollbars (if present) (includes padding + content). 2 other more compelling demo cases in attachments coming.

Border width values around the content div are scalable and several minor matters are improved in this demo case. Client area is dynamically computed. Instruction: resize the browser window and observe the presence of scrollbars in relation with the values displayed. No test done on margins, borders, padding on the root node and body node. So this test case is not entirely exhaustive.

Border width values around the content div are scalable and several minor matters are improved in this demo case. Instruction: resize the browser window and observe the presence of scrollbars in relation with the values displayed.

reassigning ...

I'm marking this as dupe of 131029. We're consistent with 4.x. Markus: next time make a usable testcase please. *** This bug has been marked as a duplicate of 131029 ***