Closed Bug 30394 Opened 24 years ago Closed 22 years ago ignores width/height=* parameters


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

Windows 95





(Reporter: bht237, Assigned: danm.moz)


(Keywords: dom0, testcase, Whiteboard: [nsbeta2-][nsbeta3-][rtm-])


(1 file)

Mozilla build 2000030308

When using with attributes
in Netscape up to version 4.7 and Microsoft IE up to 4 on Win95,
then the new window has exactly the same size as the opener.

If the opener is maximised, then the new window is maximised as well.
**** The inheriting of the fully maximised status, indicated unambiguously by
the title bar buttons, is a very important feature here. ****

Mozilla build 2000030308 opens a window that has almost 0 size and
cannot be manipulated with the mouse.

Working around this by querying the client screen size and the guessing
the size and position of the new maximised window with JavaScript appear to be
a waste of time in comparison with the efficient method using
"width=*,height=*" parameters

HTML test case:
<TITLE>New Window Test</TITLE>
function newWin(){
    var kWn=open("foo.htm","foo","width=*,height=*");
<BODY onLoad="Please maximize your window before clicking the button">
<INPUT type="button" value="Open New maximised Window" onClick="newWin()">
Correction, my apologies:
<BODY onLoad="alert('Please maximize your window before clicking the button')">
-> DOM0.
Assignee: rogerl → vidur
Component: Javascript Engine → DOM Level 0
QA Contact: rginda → desale - are you still seeing this problem in recent builds of 

From private mail from reporter:

"I Have downloaded build ID 20000409008 and tested it on Win95 OSR2.

The result is still the same (bug). I have attached a screen capture
It would be very nice to have this fixed.
Navigator 3 and 4 and also Internet Explorer 3 have the desired
behaviour, which eliminates the guesswork trying to calculate full
screen parameters (but only if the opener is already maximised).

Even better would be an option that guarantees maximised window status
such as IE's "fullscreen" option.

We are using Netscape as an application platform (nut just "browser"),
so issues like this are very important to us.

I am very pleased with the amazing development of Mozilla!"

Adding 4xp keyword, upping severity, confirming.

Severity: normal → major
Ever confirmed: true
Keywords: 4xp
Attached file test case
Harold Hsu - mail, quoting this bug number, for Bugzilla 

Adding keywords; nominating for nsbeta2.

Keywords: nsbeta2, testcase
gerv..need a test with the latest May 15 build.  Are you still seeing this?
Whiteboard: [NEED INFO]
Per a mail from
"Have not tested with the latest build but May 13 looked OK to me."

Marking WorksForMe.
Closed: 24 years ago
Resolution: --- → WORKSFORME
Verified with 2000-02-22-08.
Opens a window size about 100*100.
Should be full screen i.e. 4pixels beyond in each direction
as in Navigator 3 and 4.
Resolution: WORKSFORME → ---
Reassigning to the DOM window guy.
Assignee: vidur → danm
Putting on [nsbeta2-] radar. Not critical to beta2. 
Whiteboard: [NEED INFO] → [nsbeta2-]
cc ekrock for possible nsbeta3 nomination.
Thanks Peter, good catch. Yes, nominating nsbeta3. This is a basic 
backward-compatibility and cross-browser compatibility bug for DOM0 (basic 
JavaScript that's been supported in all browsers and widely used forever). is by far one of the most widely-used JavaScript methods and we 
need to be fully backwardly compatible, otherwise we'll break JavaScript all 
over the web. PDT team please call me if you're even thinking of not approving 
this nsbeta3. Thanks!
Keywords: correctness, nsbeta3
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
Target Milestone: --- → Future
Target Milestone: Future → M18
width/height=* now substitutes dimensions from the parent window, as did 4.x. 
Calling this fixed, except the more minor issue which this bug implies; that a 
newly opened window will inherit only the parent window's size, not its min/max 
state. That's a different problem: bug 20847 (though *that* bug states the extra 
condition that the parent window must be closed first.)
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
Summary: parameter ignored → ignores width/height=* parameters
Build 2000 090808:
The size of the new window is now larger than the maximized parent window.
Re-opened bug.
It would be nice if the maximized state could be inherited.
As suggested by
It's important because this state cannot be forced via JavaScript.
Logically, a window manager can only treat a full size window properly
(i.e. re-sizing it when reducing available screen space) if it knows
that the window is maximised.
Whether or not the window manager actually does this correctly, is another
matter that should not have an influence on Mozilla's design.
The width=*,height=* was a step in the right direction.

This is much more valuable for a cross platform browser than for others like IE.
The code to open a full size window cross platform becomes bulkier with every
new browser and platform so anything that encapsulates this a little
more is much appreciated.
Resolution: FIXED → ---
clearing nsbeta3+ for retriage, since the reason for reopening sounds different
from the original defect. If this really is a separate issue (even if related),
please open a separate bug report.
Whiteboard: [nsbeta2-][nsbeta3+] → [nsbeta2-]
Blocks: 32148
The reason for reopening is not different from the original defect:
When I write "width=*,height=*", then I specifically request inheritage.
This is different from bug 20847.
20847 is about inheriting window mode if no parameters are supplied:
A user opening a new window cannot specify parameters.
So 20847 is logically dependent on this bug: 20847 can only work if a
mechanism exists to inherit from any (in this case an open one) window.
The dependent functionality is to inherit as default which this bug
is not concerned with.

I cannot see a reason to open another bug.
The effect was first a too small window, then a too large window.
In both cases: not inherited.
No longer blocks: 32148
This is somewhat obscure, and the consequences are relatively minor. We have no
time left to fix bugs like this in N6, ->nsbeta3-/future
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
Target Milestone: M18 → Future
Nominating for rtm. Ability to provide width and height of new window is pretty 
common desire by any web developer. 
Keywords: rtm
Whiteboard: [nsbeta2-][nsbeta3-] → [nsbeta2-][nsbeta3-][rtm-]
Nominating nsbeta1 as is widely used and this is a backward
compatibility bug for window sizing behavior (which is highly noticeable to the
user and the developer alike).
Keywords: nsbeta1
Keywords: dom0
For me, Navigator 4 backwards compatibility it is no longer relevant.
I am happy to close this.
Closed: 23 years ago22 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.