107172 - Javascript handles windowsize incorrectly with scrollbars?

Status: RESOLVED DUPLICATE of bug 48634

(Core :: DOM: Core & HTML, defect)

Description

[Pauli Borodulin]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5+)
Gecko/20011026
BuildID:    2001102603

One Finnish newspaper-site has webpages at http://www.helsinginsanomat.fi which
I saw this on. I know nothing about JavaScript, so this may be error in
JavaScript they're using, but just making sure.

Seems like Mozilla's javascript, while handling window-size, calculates
incorrectly the size, and the little orange bar gots under it because
javascript-system doesn't care if there's scrollbars or not.

The source of the little orange bar is here, if it helps:
http://www.multiportal.fi/js/smallPocket.js

Reproducible: Always
Steps to Reproduce:
1. Go to http://www.helsinginsanomat.fi
2. Resize window so that scrollbars appear
3. Notice little orange bar in right bottom corner:
   It's under the scrollbars; should be some pixes from them!

Actual Results:  Orange bar is under scrollbars.
Expected Results:  Orange bar should be couple pixels away from scrollbars.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Over to dom0.  are we including the scrollbars in innerWidth/innerHeight?

Comment 2

[Boris Zbarsky [:bzbarsky]]

dom0 for real.  :)

Comment 3

[Phil Schwartau]

Confirming bug with Mozilla trunk binary 20011030xx on WinNT.

In IE4, the little orange bar is away from both the bottom and
the right scrollbar. Not by much, but it is obvious to the eye
that there is a cushion of space around it.

In Mozilla, however, the little orange bar is right up against
both scrollbars, with no space in between...

Comment 4

[Fabian Guisset]

dup of bug 48634?

Comment 5

[Pauli Borodulin]

Hmm I wouldn't agree. 48634 is about content alignment in browser window, but I
guess it has nothing to do with this? At least I don't think so :-) 

Comment 6

[Boris Zbarsky [:bzbarsky]]

The function being used in this case uses body.clientWidth as well as
window.innerWidth.  I bet both are off by the scrollbar width...

The way to go about subtracting off the scrollbar width is nsIScrollableFrame. 
For clientWidth, we already get the scrollable view from an nsIScrollableFrame
so this is either a bug in view (gives us wrong clip size) or the page is not
using clientWidth as I think it is...

Fabian, some testcases of innerWidth and clientWidth with and without scrollbars
would be great.  :)

Comment 7

[Johnny Stenback (:jst)]

The little orange bar doesn't show up at all in mozilla right now. My guess is
that this is due to the site not doing the right thing for mozilla, but I could
of course be wrong. Not a mozilla1.0 stopper, let me know if you disagree. Any
more input on this would be greatly appreciated.

Comment 8

[Deleted User]

Is this bug considered resolved?  I have a page that seems to calculate
scrollbars incorrectly (ie. it turns them on before they're really needed),
regardless of JavaScript; I can cause the scrollbars to appear early simply by
manually resizing the window.

If you go to http://everquest2.station.sony.com/media.jsp#5 and choose an image
to look at, the image window that pops up with have scrollbars (though it
shouldn't need them), and if you resize to make the scrollbars disappear and
then re-shrink they still appear too early.

Comment 9

[CoL]

Seems this bug is still alive:(
Check this simpe html:

http://dev.gear.hu/files/samples/window.open.scrollbars.html

Can not define: scrollbars=no, if an image is in popup which is larger then the
popup width,height, and image has no specified with,height attribute.

I made 3 testcase, please check them out.
1)if an image tag is written in popup, but no width,height attribute specfied,
and scollbars=no was set. (scrollbars appears, however scrollbars are disabled
from window.open)
2)the same case, but there is a with attribute for image. In that case
scrollbars wont be there. Behaviour ok.
3)A table which is bigger then the popup. There is no scrollbars, so it works fine.

Tested: mozilla 1.2b (2002101612), and Netscape 7 (20020823)

Comment 10

[CoL]

Hm, checkin once, with a ruler:) seems, mozilla sets the width and height at a
popup for outterwidth and height, not inner. Under Win2k (default style) width +
10, height + 30 need to be set.
However this bug (once scrollbars ar there one not) is something else, not just
the bad size check.

Comment 11

[Pauli Borodulin]

Mmkay. Maybe small update is needed on this. 

This bug occured with site http://www.helsinginsanomat.fi, but they have removed
the orange bar I mentioned. They updated it and it's now on
http://www.oikotie.fi/. I contacted them, and they made the gap bigger so it
won't go under Mozilla's scrollbars (how kindly!).

As I can see, the original problem still exists.

Comment 12

[Boris Zbarsky [:bzbarsky]]

This is most definitely a dup; see comment 6

*** This bug has been marked as a duplicate of 48634 ***