Closed
Bug 30394
Opened 25 years ago
Closed 24 years ago
window.open() ignores width/height=* parameters
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: bht237, Assigned: danm.moz)
Details
(Keywords: dom0, testcase, Whiteboard: [nsbeta2-][nsbeta3-][rtm-])
Attachments
(1 file)
|
346 bytes,
text/html
|
Details |
Mozilla build 2000030308
Background:
When using Window.open() with attributes
"width=*,height=*"
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. ****
Bug:
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:
<HTML>
<HEAD>
<TITLE>New Window Test</TITLE>
<SCRIPT>
function newWin(){
var kWn=open("foo.htm","foo","width=*,height=*");
}
</SCRIPT>
</HEAD>
<BODY onLoad="Please maximize your window before clicking the button">
<FORM>
<INPUT type="button" value="Open New maximised Window" onClick="newWin()">
</FORM>
</BODY>
</HTML>
Correction, my apologies:
<BODY onLoad="alert('Please maximize your window before clicking the button')">
|
||
Comment 2•25 years ago
|
||
-> DOM0.
Assignee: rogerl → vidur
Component: Javascript Engine → DOM Level 0
QA Contact: rginda → desale
|
||
Comment 3•25 years ago
|
||
bht@actrix.gen.nz - are you still seeing this problem in recent builds of
Mozilla?
Gerv
|
|
||
Comment 4•25 years ago
|
||
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
image.
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.
Gerv
|
||
Comment 5•25 years ago
|
||
|
|
||
Comment 6•25 years ago
|
||
Harold Hsu - mail asadotzler@netscape.net, quoting this bug number, for Bugzilla
permissions.
Adding keywords; nominating for nsbeta2.
Gerv
gerv..need a test with the latest May 15 build. Are you still seeing this?
Whiteboard: [NEED INFO]
Per a mail from bht@actrix.gen.nz:
"Have not tested with the latest build but May 13 looked OK to me."
Marking WorksForMe.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
|
Reporter | |
Comment 10•25 years ago
|
||
2000-07-12-15
Opens a window size about 100*100.
Should be full screen i.e. 4pixels beyond in each direction
as in Navigator 3 and 4.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
|
||
Comment 11•25 years ago
|
||
Reassigning to the DOM window guy.
Assignee: vidur → danm
Status: REOPENED → NEW
|
||
Comment 12•25 years ago
|
||
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [NEED INFO] → [nsbeta2-]
|
||
Comment 13•25 years ago
|
||
cc ekrock for possible nsbeta3 nomination.
|
||
Comment 14•25 years ago
|
||
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).
window.open() 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
|
|
||
Comment 15•25 years ago
|
||
nsbeta3+
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
Target Milestone: --- → Future
|
|
||
Updated•25 years ago
|
Target Milestone: Future → M18
|
Assignee | |
Comment 16•25 years ago
|
||
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.)
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Summary: Window.open() parameter ignored → window.open() ignores width/height=* parameters
|
|
Reporter | |
Comment 17•25 years ago
|
||
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 danm@netscape.com
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
|
|
||
Comment 18•25 years ago
|
||
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-]
|
|
Reporter | |
Comment 19•25 years ago
|
||
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
|
|
||
Comment 20•25 years ago
|
||
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
|
||
Comment 21•25 years ago
|
||
Nominating for rtm. Ability to provide width and height of new window is pretty
common desire by any web developer.
Keywords: rtm
|
|
||
Comment 23•24 years ago
|
||
Nominating nsbeta1 as window.open 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
|
|
Reporter | |
Comment 24•24 years ago
|
||
For me, Navigator 4 backwards compatibility it is no longer relevant.
I am happy to close this.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•