17311 - window.open dimensions should be inner size not outer size

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[Dan Rosen]

after submitting my last bug pertinent to the same url, i realized i had more
problems with it... apologies for redundancy.

<a href="javascript:open(...)"> in addition to opening a new window will
redirect the current frame to a blank window whose url is "javascript:open
(...)". additionally, open does not respect scrollbars=no (as i reported a
couple minutes ago). there may be other lurking problems as well.

Comment 1

[Mike McCabe]

Are javascript: urls working yet?  Last I checked, no.  I think there's other
bugs filed against that.

Could you confirm that the problems you see occur with window.open?  Thanks.

Comment 2

[Dan Rosen]

I'm marking but 17307 as a dup of another bug, but note the comment there from
[e-mail] to the effect of "the window size specified in the parameters
ought to be the inner size (not including window-manager specific borders, etc.)
rather than the outer size." Also, scrollbars=no is not respected regardless of
window size.

So, yes, I can pretty confidently say that this is a problem with window.open.

Comment 3

[Dan Rosen]

To clarify: parameters specifying window size should specify top-level frame
size, and not literally (decorated) window size. This may not be just a
JavaScript problem, but I cannot confirm this.

The scrollbar problem is a different bug entirely.

Comment 4

[Eric Pollmann]

I mentioned this to Nisheeth thinking he might have touched this code recently.
He hasn't, but between the two of us, we narrowed this down to a routine of
interest:

mozilla/dom/src/nsGlobablWindow.cpp
GlobalWindowImpl::SizeAndShowOpenedWebShell

Danm and Hyatt may know something about this according to cvs blame?

Comment 5

[Mike McCabe]

Eric -

Could you reassign this appropriately?

Thanks -

Comment 6

[Mike McCabe]

Reassigning to pollmann to reassign.  (Sorry, Eric.)

Comment 7

[Eric Pollmann]

Giving this do Dan, as he might be able to make heads or tails out of it.

Comment 8

[Eric Pollmann]

See related bug 7888, which can probably be closed out.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The window.open sizes seem to be correct for me in Linux apprunner, at least by
comparing the windows to those from NN 4.61, on the page:
http://ww2010.atmos.uiuc.edu/(Gl)/wx/satellite.rxml .
(All of the links in main part of the page open a sized window.)

Comment 10

[Dan Rosen]

Uh, things were broken in linux NN4.x too, so parity isn't what you're aiming
for ;) Definitely check for exact pixel-per-pixel correctness (take a
screenshot in the gimp and use the measuring tool, or some such, to make sure).

BTW, bugzilla thinks this is a DOM Level 0 bug. Is this correct? Sounds wrong.

Comment 11

[Dan M]

related to 3338,9606,18104,19003

Comment 12

[Dan M]

bulk moving all window-size-off-by-a-couple-of-pixels bugs to more distant 
milestone.

Comment 13

[Dan Rosen]

Many pages with precise design constraints (art pages, most commonly) will not
be displayed properly if this sort of bug goes ignored. This will make many
people very unhappy...

Comment 14

[Dan M]

Not calling it unimportant, but in the scheme of things, "hmmm, that's not quite 
right" bugs lose when they vie for my time with "this doesn't work at all, 
where's my gun?" bugs. While we're here, could you add a URL for the ugliest 
failure you can think of to the bug report, just for future reference? I couldn't 
especially see anything at the spot given in the URL field.

Comment 15

[Dan Rosen]

The url given isn't a particularly ugly failure, but it displays a vertical
scrollbar it shouldn't, because it's off by a couple pixels. I would be
incredibly surprised if this bug were more than a couple lines of code to fix...

Comment 16

[leger]

Updating QA contact to gerardok.

Comment 17

[Hixie (not reading bugmail)]

See also bug 7888.

Comment 18

[Peter Trudelle]

Mass moving M18 bugs to M19

Comment 19

[ekrock's old account (dead)]

Nominating nsbeta2. We have to start drawing a line on DOM0 backward 
compatibility; these bugs are supposed to be a high priority for nsbeta2 per the 
beta2 criteria.

Comment 20

[ekrock's old account (dead)]

Setting to [nsbeta2+][6/15].

Comment 21

[ekrock's old account (dead)]

Since this probably won't make nsbeta2, nom. nsbeta3 & rtm, *strongly* recc. 
nsbeta3 hard-stop. window.open with size control is widely used ever since Nav4 
and there is no standards-based equivalent in the W3C DOM; either this works 
correctly, or we've got no way to specify the window's inner width on opening. 
Both content sites and web applications need the ability to open new windows at 
a particular size--and often one needs to do that in terms of the inner (content 
area) width, not the outer (content area + chrome) width. Getting this correct 
by rtm is a critical part of our web content and web application platform.

Comment 22

[Jim Roskind]

Cleaning up status whiteboard and marking beta2 minus (6/15 is passed)

Folks are too doomed to handle this in time for beta2

Comment 23

[Peter Trudelle]

nsbeta3+

Comment 24

[Dan Rosen]

This was marked as a DOM level 0 bug, which I can't for the life of me
believe... Marking as XPToolkit/Widgets for lack of a better category.

Also, DanM, do you think this would be easy enough for me to fix? If so, go
ahead and reassign it...

Comment 25

[Dan M]

  It's already been fixed. Travis cleaned this stuff up a couple of months ago. 
window.open(...,"width,height") works as if you'd specified 
innerWidth,innerHeight, as this bug requests. Test case:

(main window)
<html><body>
<form>
<input type=button value="Open (width,height) (600,400)"
 onclick="window.open('17311-2.html','_blank','width=600,height=400')"><br>
<input type=button value="Open (inner) (600,400)"
 
onclick="window.open('17311-2.html','_blank','innerWidth=600,innerHeight=400')">
<br>
<input type=button value="Open (outer) (600,400)"
 
onclick="window.open('17311-2.html','_blank','outerWidth=600,outerHeight=400')">
<br>
</form>
</body></html>

(secondary window, named 17311-2.html)

<html><head><script>
  function sizeDescription() {
    var sizeStr;
    sizeStr = "<h5>current window dimensions</h5>";
    sizeStr += "inner Width "+innerWidth+"<br>inner Height "+innerHeight+"<br>";
    sizeStr += "outer Width "+outerWidth+"<br>outer Height "+outerHeight+"<br>";
    return sizeStr;
  }
</script></head><body>
<script>
  document.write(sizeDescription());
</script>
</body></html>

demonstrates this. Note that it does, however, point out some other problems. 
But those would be different bugs.