116610 - New windows through open() and target= come up wrong size

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Danek Duvall]

In 2001-12-22, whenever new browser windows are opened using the Javascript
open() function or by clicking on a link that has a new window as a target, the
new window comes up with the wrong size -- neither the size of the window that
opened it nor the default size, but, at least in my case, 615x480.

This does not happen when middle-clicking on a link to open it in a new window,
and File/New Navigator Window also brings up a window of the right size.

Comment 1

[John Morrison]

I can't reproduce this with 2001122806 Linux rh6.1/gnome/enlightenment. Each 
way that I use to open a new window (see examples above), I get a new window in 
the same, current default size. Don't know why this is not working for you.

Could you try another build, and also (1) note your windowmanager/desktop info,
and (2) find the file 'localstore.rdf' in your current profile and load it 
directly into the browser content area [and see if any XML errors are 
reported]. Thanks.

Comment 2

[doeni]

I am seeing the same behaviour on two different machines :
- Slackware 7.0 with Gnome/Enlightment
- Slackware 8.0 with Openwin
The problem looks specific to Linux (at least it does not reproduce on Windows
builds).
I will attach a small HTML page with which I can reproduce the problem.
I've made the test with BuildId 2001122808.

The size of the new window (as shown by xwininfo) is:  Width: 615 Height: 480,
whereas the main browser window size is: Width: 843 Height: 626

I can load the localstore.rdf file from my profile without problem.

Comment 3

[doeni]

Attachment: The test page

Comment 4

[Nikita]

I have this same problem on Build 2001122106, on a Mac machine running OS 9.1. I
would say that it's more the open() command that has the problem - no matter
what size is specified in the parameters, a window comes up that is of a
different size than the one needed. This doesn't happen in Netscape 6.2, however.

Comment 5

[Matthew Cline]

I have the same problem with TARGET links on Linux 2.4.17 i686, build 2002011614,
XFree86 4.1.0, KDE 2.2.2, using the default KDE window manager, RedHat 6.1; I've
had this problem for at least sevaral weeks.  Confirming bug; OS -> "All" and
Platform -> "All", since it's been observed on a Mac.

Comment 6

[Joseph Delaney]

This is also affecting Fizzila/MacOS X (Build 2002011808), where new windows 
open to fill the entire screen, then snap down to the default size, it seems
regardless of how they are opened. Also the position of  the new window opens at
the top left of the screen rather than cascading (so it hides the other windows,
instead of leaving their title bars showing). 

Comment 7

[Axel Hecht]

me sees that, too. The window size is somewhat close to the original size of
a window with a fresh profile. If I don't resize the window, the new window
get's opened at the same size. (The initial window was sized slightly different,
though.)
If I middle-click to open the new window in a new window ;-), I get the size
as it is currently set. Sounds to me like the persist isn't read if the
window is opened by target='_blank'.
xul:window.open('aURL','name') opens the same size, if I start to give options,
the size is completely different.

Comment 8

[Joseph Delaney]

My deepest apologies. Doing a fresh installation without
preferences/cache/bookmarks etc completely fixed this problem for me on Mac OS X. 

Oops. I should have done that before.

Comment 9

[Axel Hecht]

To clear this up, I do work on a new profile now, and still see this bug.
So the dementi by jpd is probably only regarding the effects he described for OS X

Comment 10

[Matthias Versen [:Matti]]

*** Bug 124879 has been marked as a duplicate of this bug. ***

Comment 11

[Anthony DeRobertis]

FYI: I my case, this is a regression from 0.9.7 to 0.9.8. Also, killing
localstore did not fix it.

Enlightenment Version: 0.16.5
Last updated on: $Date: 2000/07/28 21:29:56 $

Debian GNU/Linux testing

Linux bohr 2.4.16 #2 SMP Wed Nov 28 05:25:00 EST 2001 i686 unknown

XFree86 Version 4.1.0.1 / X Window System
(protocol Version 11, revision 0, vendor release 6510)
Release Date: 21 December 2001

Mozilla 0.9.8, build ID 2002020415

Comment 12

[Olav Vitters]

*** Bug 118925 has been marked as a duplicate of this bug. ***

Comment 13

[Anthony DeRobertis]

This bug appears to be intermittant. It doesn't happen, in one very unscientific
test, to about 20 of 200 pop-ups. I was loading the following:

<html><head><title>Hello, World!</title></head>
<body bgcolor="#fff7f7" onload="while (1)
window.open('http://helloworld.gearboxx.net/')">
  <h1 align="right">Hello,</h1>
  <h2 align="right">World!</h2>
  <h3 align="center">Anthony's Random Test Site</h3>
  <h4 align="left">Now with 50% less HTML errors</h4>
  <h5 align="right">...but 100% more eyeball busting.</h5>
</body></html>

And noticed some of the windows came up 800x600, instead of 640x480. (Please
don't ask why I was running it, but FYI it got to around 200 windows, and 300MB
of RAM, before 0.9.8 crashed.)

Comment 14

[David Illsley]

*** Bug 123542 has been marked as a duplicate of this bug. ***

Comment 15

[Steevithak]

Just downloaded Mozilla 0.9.9 and this bug seems to be alive and well. On my Red
hat 6.1 box, open() and target= open as tiny little windows 100% of the time.
The good news is that on my NT4 and Red Hat 7.2 box it is almost never happening
now. 0.9.7 and older work fine in all cases. This seems to be limited to 0.9.8.
and 0.9.9 ... only fix I've found it to return to 0.9.7.
 

Comment 16

[Anthony DeRobertis]

I can confirm this still happens for me with 0.9.9 on Debian testing. Exact size
is 615x480, as other reporters have mentioned. Perhaps my origonal 640x480 was
mistaken.

Comment 17

[Michiel van Leeuwen (email: mvl+moz@)]

I found out the following:

in xpfe/appshell/src/nsXULWindow.cpp a 615*480 window is opened. Somehow, during
the creatinf of this window, a resize event is fired. Always, when a resize
event occurs, in xpfe/appshell/src/nsWebShellWindow.cpp a timer starts and waits
half a second before setting that size as the new default. Most of the times,
the creation of the window takes longer than that. Now the original size of
615x480 is the new default size. At the end of the creation process the window
is given the default size, which happens to be wrong at this time.

When the delay to set the default size (nsWebShellWindow.cpp line 172) is
changed to someting like 3 seconds, the window gets the correct size.
Another solution seems to be to change nsXULWindow.cpp to use 
nsIAppShellService::SIZE_TO_CONTENT as size.
The best solution is ofcourse to prevent the initial resize event. But I don't
know how to do that.

Hope this helps.

Comment 18

[Danek Duvall]

This seems to be fixed as of at least a 2002042510 build (and one two hours
later).  I see correct behavior on both Solaris and Linux, under fvwm.

Comment 19

[doeni]

Confirming it is fixed in :
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020425

Comment 20

[Axel Hecht]

tried with a CVS build
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.9+) Gecko/20020426
on a new profile, still doesn't work for me.

Comment 21

[Michiel van Leeuwen (email: mvl+moz@)]

Does not work for me too, linux 2002042607

Comment 22

[Steevithak]

This is still broken for me on Red Hat 6.1 using Mozilla 1.0RC3. Should I take
this to mean that opening new windows will be broken in the final 1.0 too or is
there any hope this will be fixed before the final release? I would think being
able to correctly open a new browser window would be considered at least a
moderately important function to have available in a release version of a web
browser!

Comment 23

[Dawn Endico]

links with target="_blank" work for me on redhat 7.2 and redhat 6.2.

I don't know of any test cases with open()

Comment 24

[Dawn Endico]

i should have noted that i was using installer builds in both cases. 
on redhat 7.2, a may 22 branch build and rc3 on redhat 6.2

Comment 25

[Dan M]

.

Comment 26

[Dan M]

Attachment: disable window size persistence before chrome is loaded

WFM; I've noticed no window sizing problems in any recent (< 6 mos. old) build.
But Michiel's comment 17 raises some questions. The Steps to Window Sizing
outlined there aren't quite correct. Here's how it works in more detail:

(1) A new window.open() window is indeed initially created at 615x480. (1a)
*nux-only: the window has to be resized to get it to be 615x480. The size is
not immediately persisted to localstore but (1b) *nix-only: a timer is set to
do that in 500 msec. That's the delay Michiel noticed in nsWebShellWindow.cpp
line 172.

Next (2) the window's chrome is loaded from XUL. Then (3) the window is sized
to its persistent size stored in localstore.rdf (really a memory cache of
that). (4) This new size is stored back to localstore immediately, and (5) a
timer is set to store it again in 500 msec (crufty and inefficient, but let's
maybe get back to that.)

Next (6) the window's size persistence is removed. That is, subsequent changes
to the window's size will no longer be persisted to localstore. After that, (7)
the window is sized once again to the size given in the window.open(size)
parameters. This time the new size is not stored in localstore (because of step
6) but (8) the timer is restarted. 500 msec later, more or less, (9) the timer
will fire but again do nothing because of step 6.

The 1a and 1b steps don't happen on Windows; I believe they're linux-specific.
And even there, only to the first newly opened window, or something like that.
(This part I'm unsure of, but anyway I hit those steps during testing only the
first time after launching and loading a test page.)

In theory the persistence timer should fire only once after all the window
jiggling has settled down. And it should do nothing because of step 6. The
persistent reader (sorry) will have noticed, though, that there's a problem
here. If the 500 msec timer fires between steps 1b and 3, the persistent size
data will be overwritten with the unwelcome and useless 615x480 numbers. Even
so I don't understand why the window isn't sized anyway in step 7. The
persistent size should be incorrect, but the window should size shouldn't be.

Despite my not quite understanding what's going wrong, Michiel's observation
that a longer timer delay fixes this problem makes me think that the timer
firing between steps 1b and 3 is what's going wrong here. Step 2 can take a
while to finish. It must be very painful to open new windows on your system.

The attached patch will probably fix this. It prevents step 1b. Can anyone who
is seeing this problem test it?

Comment 27

[Chris Siebenmann]

 This remains sporadically broken for me on current CVS builds on
Red Hat 7.1 (using fvwm2 2.4.3 as my window manager) for 'target="_blank"'
windows. (I can't speak for Javascript; I browse with it off almost all of
the time.) When it happens it's a heisenbug; sometimes it happens, sometimes
it doesn't, even within the same browsing session.

I suspect a timing issue, which is probably an obvious diagnosis.

Comment 28

[Dan M]

Attachment: disable window size persistence before chrome is loaded

Oops. See comment 26 but use this patch instead, because it actually compiles.
Looking for feedback from someone who can reproduce the bug.

Comment 29

[Michiel van Leeuwen (email: mvl+moz@)]

I tried the patch, and it works for me.

About javascript: When opening a window with winodw.open() and no size
parameters,  the windows is the wrong size (without the patch, with the patch it
is ok). When window.open has size arguments, the window is the correct size,
with and without the patch.

Comment 30

[chunnuan chen]

Has the patch been checked intot he nightly build? If so, I would like to test
it out. The 1.0 RC3 download still has the problem on my Mandrake  8.2. 

Comment 31

[Brian Ryner (not reading)]

Comment on attachment 84994 [details] [diff] [review]
disable window size persistence before chrome is loaded

r=bryner

Comment 32

[jag (Peter Annema)]

Comment on attachment 84994 [details] [diff] [review]
disable window size persistence before chrome is loaded

sr=jag

Comment 33

[Dan M]

Patch is in the trunk. It'll show up in tomorrow's builds. Calling it fixed (I
can't see the problem on my machine, anyway).

Comment 34

[Steevithak]

Just tried build 2002060308 and it works for me on Red Hat 6.1. Woohoo!