Closed Bug 30394 Opened 25 years ago Closed 24 years ago

window.open() ignores width/height=* parameters

Categories

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

x86
Windows 95
defect

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: bht237, Assigned: danm.moz)

Details

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

Attachments

(1 file)

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')">
-> DOM0.
Assignee: rogerl → vidur
Component: Javascript Engine → DOM Level 0
QA Contact: rginda → desale
bht@actrix.gen.nz - are you still seeing this problem in recent builds of Mozilla? Gerv
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
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: 4xp
Attached file test case
Harold Hsu - mail asadotzler@netscape.net, quoting this bug number, for Bugzilla permissions. Adding keywords; nominating for nsbeta2. Gerv
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 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
Verified with 2000-02-22-08.
Status: RESOLVED → VERIFIED
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 → ---
Reassigning to the DOM window guy.
Assignee: vidur → danm
Status: REOPENED → NEW
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). 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
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.)
Status: NEW → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Summary: Window.open() parameter ignored → window.open() 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 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 → ---
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
[rtm-]
Whiteboard: [nsbeta2-][nsbeta3-] → [nsbeta2-][nsbeta3-][rtm-]
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
Keywords: dom0
For me, Navigator 4 backwards compatibility it is no longer relevant. I am happy to close this.
Status: REOPENED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: