Closed Bug 30394 Opened 24 years ago Closed 22 years ago

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

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: bht237, Assigned: danm.moz)

Details

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

Attachments

(1 file)

test case
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')">

-> 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: 24 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: 24 years ago → 23 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: 23 years ago → 22 years ago
Resolution: --- → WORKSFORME

          You need to log in
          before you can comment on or make changes to this bug.