Closed
Bug 44544
Opened 25 years ago
Closed 21 years ago
Scrollbars appears with dynamic DIVs( using innerHeight )
Categories
(Core :: DOM: Events, defect, P4)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: sea, Assigned: joki)
Details
(Keywords: dom1, testcase)
Attachments
(2 files)
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.15 i586; en-US; m17)
Gecko/20000703
BuildID: 2000070308
Using JavaScript to dynamically assign a DIV's height and width with
document.innerHeight and document.innerWidth does not skrink correctly. If the
window is enlarged it works correctly, but shrinking results in scrollbars.
Reproducible: Always
Steps to
Reproduce:
1.Use Sample Code
<HTML>
<head>
<style type="text/css" >
<!--
#SIDE {
Height:0;width:75;position:absolute;left:5;top:57;background:#FFF3CA;
Border: 1 solid black;
}
#HEADER {
background:#FFF3CA; height:50;width:0;position:absolute:top:0;left:5;
border: 1 solid black;
}
-->
</style>
<script LANGUAGE="Javascript">
<!--
function Test()
{
document.getElementById('HEADER').style.width = window.innerWidth -
14;
document.getElementById('SIDE').style.height = window.innerHeight - 64;
}
window.onresize=Test;
window.onload=Test;
//-->
</script>
</head>
<body bgcolor="#DFF8C8 >
<div ID="SIDE"> </div>
<div ID="HEADER"> </div>
</body>
</html>
3. There should be NO scrollbars. If there is then I messed up on the copying
over( Mozilla doesn't like Cut and Paste ).
4. Now shrink the window. Notice that
the scrollbars show up.
I don't know if this a Browser, or DOM problem. The
JavaScript event handling is firing though.
|
||
Comment 1•25 years ago
|
||
Confirmed on Linux 2000070308.
Attaching the reporter's HTML for easier verification.
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
|
||
Comment 2•25 years ago
|
||
|
|
||
Comment 3•25 years ago
|
||
Argh, sorry.. On further consideration and viewing the testcase in IE5 and
Netscape 4.71, this JavaScript has errors. Reporter, if this is your mistake,
please attach a new testcase and we can reopen.
Specifically:
"getElementById is not a function."
I'm no JavaScript God, so please feel free to correct me or the script.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
the getElementById() does exist in the documented Mozilla DOM, and from all the
sample coding I've seen this is the only way to access elements on the page.
That is correct:
Netscape does not support the getElementById() function but it is in the W3
standard, thus Mozilla *should* support it correctly.
IE5 does not support the document.innerWidth correctly so this script would not
work there. IE5 will report that as undefined and thus will not work.
As far as I know this script will *only* work in Mozilla, and maybe Opera( but I
doubt that )
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
|
|
||
Comment 5•25 years ago
|
||
gerardok@netscape.com, is Moz going to support this? I vote that it does.. if
that means anything. :)
gerarkdok@netscape.com, is the getElementByID() going to be the only function
we'll be able to use to get to elements?
I mean say I make a Div <Div ID="BOB" ></DIV>
Is mozilla going to support something like:
document.BOB.style.width or BOB.style.width, like I believe IE and Netscape do.
It's fine that Mozilla sticks to standards, but this does make it a little
easier to code. Could this be presented as an option, as well as the standard?
|
||
Comment 7•25 years ago
|
||
Code like document.BOB.whatever will not work in mozilla,
document.getElementById() is what should be used in all cases where a element is
refered to by ID through the DOM.
As for the real problem here, my guess is the the onresize handler is fired too
early in mozilla, i.e. we fire the onresize handler before the window is resized
and this leads to the innerWidth&Height being the width&height of the window
before it's resized. Reassigning to Joki for futher investigation...
Assignee: jst → joki
Status: REOPENED → NEW
This bug has been marked "future" because the original netscape engineer working
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way
-- please attach your concern to the bug for reconsideration.
Target Milestone: --- → Future
|
||
Updated•24 years ago
|
Component: DOM Level 1 → DOM Style
|
|
||
Updated•24 years ago
|
Component: DOM Style → DOM Events
|
||
Comment 10•23 years ago
|
||
I don't use Linux but if you want your #SIDE div to always be located at 5px
from the inner bottom edge of the browser's viewport, then you might consider
the css bottom property; using document.body.clientHeight instead of
window.innerHeight in your script is also another possibility (notwithstanding
the onresize event not being continuously fired on a resize - see bug 114649;
there wouldn't be any scrollbars appearing and disappearing IMO). Same thing
with your #HEADER div: use right:7px or document.body.clientWidth instead of
window.innerWidth in your script.
You should always define your css units in your style and in your script
function as well (i.e. + "px").
Attachment coming as a - hopefully - suitable workaround.
|
|
||
Comment 11•23 years ago
|
||
Using bottom and right css properties should not create any scrollbars when
resizing.
|
||
Updated•23 years ago
|
|
|
||
Updated•23 years ago
|
Priority: P5 → P4
|
||
Comment 12•22 years ago
|
||
The real problem here is that no measurement is used.
javascript:void(Test=function(){document.getElementById('HEADER').style.width =
(window.innerWidth - 16) + "px"});
Try it.
Can this be marked as invalid?
|
|
||
Comment 13•22 years ago
|
||
Garrett, your code needs to consider the margins on the body. I downloaded the
reporter's testcase, then declared
body {margin: 0px;}
and then change the 14 for 16 in the instruction
document.getElementById('HEADER').style.width = window.innerWidth -
16;
/* width of vertical scrollbar is 15 pixels regardless of scr. reso. */
and walla!: no scrollbar appearing when increasing or reducing window inner
dimensions.
The other way is to add the default [hidden] margin on body in the assignment
instruction:
document.getElementById('HEADER').style.width = window.innerWidth -
24;
Notes:
a) - 23 does not generate scrollbars; - 22 will.
b) when both scrollbars have appeared dynamically and then disappear (at the end
of a window resizing), there is 23 pixels gap at the right side of the
div#HEADER, not 8 like a webdesigner would prefer, expect. The code does not get
perfectly updated.
c) If you decrease the width (and only the width) of the window, then the
generated horizontal scrollbar during the resizing reduces the height of the
*_strict_* content area cascade-causing the vertical scrollbar to appear. There
is an auto-feedback update which is not done, completed when the width
reduction/resizing ends. One ends up with a maximized vertical xul:thumb.
MSIE 6 for windows "solved" this dynamic update difficulty by setting
html {overflow:scroll; overflow-y:scroll;}
body {overflow:visible;}
creating a permanent visible vertical scrollbar.
Anyway, I really think this bug should be resolved as WORKSFORME.
XP Pro SP1, build 2003010908
|
|
||
Comment 14•21 years ago
|
||
For various and numerous reasons (some of which were explained in the last
comments), I'm RESOLVING this bug as WORKSFORME.
If you feel this is a mistake, then reopen it and explain why (preferably with a
reduced testcase).
Status: NEW → RESOLVED
Closed: 25 years ago → 21 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•