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.
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.
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.
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.
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).
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.
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.
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
*** Bug 124879 has been marked as a duplicate of this bug. ***
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 188.8.131.52 / X Window System (protocol Version 11, revision 0, vendor release 6510) Release Date: 21 December 2001 Mozilla 0.9.8, build ID 2002020415
*** Bug 118925 has been marked as a duplicate of this bug. ***
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.)
*** Bug 123542 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
Confirming it is fixed in : Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020425
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.
Does not work for me too, linux 2002042607
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!
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()
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
Created attachment 84964 [details] [diff] [review] 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?
Created attachment 84994 [details] [diff] [review] 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.
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 on attachment 84994 [details] [diff] [review] disable window size persistence before chrome is loaded r=bryner
Comment on attachment 84994 [details] [diff] [review] disable window size persistence before chrome is loaded sr=jag
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).
Just tried build 2002060308 and it works for me on Red Hat 6.1. Woohoo!