Javascript handles windowsize incorrectly with scrollbars?




DOM: Core & HTML
17 years ago
15 years ago


(Reporter: Pauli Borodulin, Assigned: jst)


Windows 2000

Firefox Tracking Flags

(Not tracked)





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

One Finnish newspaper-site has webpages at 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:

Reproducible: Always
Steps to Reproduce:
1. Go to
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.
Over to dom0.  are we including the scrollbars in innerWidth/innerHeight?
dom0 for real.  :)
Assignee: rogerl → jst
Component: Javascript Engine → DOM Level 0
QA Contact: pschwartau → amar

Comment 3

17 years ago
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...
Ever confirmed: true

Comment 4

17 years ago
dup of bug 48634?

Comment 5

17 years ago
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 :-) 
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

16 years ago
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.
Target Milestone: --- → mozilla1.1

Comment 8

16 years ago
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 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

16 years ago
Seems this bug is still alive:(
Check this simpe 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
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

16 years ago
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.


16 years ago
Target Milestone: mozilla1.1alpha → ---

Comment 11

15 years ago
Mmkay. Maybe small update is needed on this. 

This bug occured with site, but they have removed
the orange bar I mentioned. They updated it and it's now on 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.
This is most definitely a dup; see comment 6

*** This bug has been marked as a duplicate of 48634 ***
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.