It should have the same position and size as the opener. In comparison with older versions of Mozilla and Netscape 4, this appears to be wrong behavior. Mozilla 1.7.1 Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.1) Gecko/20040707
Gonna need some more details, fella. This works fine for me. Is your opener window maximized? Fullscreen? Does it like green eggs and ham? Are you using a multiple-monitor system? What extensions are you running, and does disabling them have any effect? Does a new profile have any effect? And by the way, the new window's position is supposed to be *not* the same as the opener's, unless it was maximized, of course.
The opener window is maximized, not full screen. It shows "Navigation Toolbar", "Status Bar", and "Component Bar" only. No multiple-monitor system. 800*600. No extensions. New profile I don't know. After running this testcase, sometimes new windows opened manually open with the following values: x=77, y=120, w=112, h=110, same as in the testcase. The testcase, however, always reproduces on my system.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a3) Gecko/20040804 Win98 SP1, 800x600, Mozilla maximized, testcase loaded in another tab Opener : x:4 y:4 w:808 h:580 New Window: x:4 y:0 w:550 h:572 New Window: x:4 y:0 w:550 h:572 (after starting browser anew) DOM Inspector - Box Model: HTML: x:0 y:0 w:542 h:8 BODY: x:0 y:0 w:526 h:0 The new window has a width of about 2/3 of the screen, and full height, statusbar covering statusbar of the opener, title bar covering titlebar of the browser. So height seems to be totally wrong. DOM Inspector - Box Model of opener window, all bars shown: HTML: x:? y:? w:798 h:376 BODY: x:? y:? w:782 h:360 DOM Inspector - Box Model of opener window, 4 bars collapsed: HTML: x:? y:? w:798 h:484 BODY: x:? y:? w:782 h:468
Frankly I'm not sure what half that stuff in the last two comments is. bht: Your testcase source explicitly opens a window with all chrome disabled except the statusbar. Since you see other chrome as well (the "Navigatior Toolbar" and the "Component Bar" (what's that?)) you must have some of the dom.disable_window_open_feature.* prefs set. Is that a factor in your testcase results? Hermann: Lots o' numbers yes, but I don't know how to interpret them. For one thing I'd expect the body element to be larger with the toolbars etc. collapsed, so I'm especially not sure of your meaning with those last numbers. Is that as expected, or a surprise? All: There's no general bug with the size of a new window not matching its opener's. Please do try again with a new profile, which will ensure that you're using clean, uncustomized preferences (and no extensions, though apparently that's not a problem with bht). Then size the opener window fairly small -- not maximized or fullscreen -- and center it on your monitor. Do the test. I feel certain there will be no problem: the new window will be the same size, and offset down and to the right. With that as a starting point, hopefully you'll be able to pin down what setting or preference or state or circumstance is causing the problem.
Created attachment 155653 [details] Screenprint gif file danm: I described the window features of the _opener_ only via the text of the checked menu items in the View -> Show/Hide menu. I don't have any dom.disable_window_open_feature.* prefs set. In the attached image you can clearly see a crippled new window in front of the maximized parent. If you tell me how to get around this stupid s0ixci0p.slt profile directory stuff that causes me problems of re-connecting to an original profile then I could do the test as you suggested, but only very reluctantly.
Yes, sorry. Clearly you were talking about the opener; I spaced that. I also notice you're seeing something different than what Hermann is seeing. The New Profile experience isn't supposed to be painful. The idea is to set one up temporarily and not worry about your mail and settings from your original profile being unavailable while using the new one. Reproducing the error by copying your settings one by one from the old profile to the new is more painful, but doesn't damage the old profile. Delete the new profile once you're done testing and everything's back to normal. Personally I do this not by using the Profile Manager, but by temporarily renaming the profile directory. Quit Mozilla, and in Windows 98 Command Shell speak, cd \Windows\Profiles\<login name>\Application Data\ rename Mozilla Mozilla.tmp Once finished testing, rmdir /S /Q Mozilla rename Mozilla.tmp Mozilla Don't do this if you're not comfortable messing with such things, of course. bht, I can't find anywhere in this bug where you say you've tried this from an unmaximized opener window. That of course is the first thing you should try. I suspect your problem is simply that the persistent window size is corrupt. See (similar) bug 240381 comment 5.
If I delete all profile data under s0ixci0p.slt and start fresh, then I get: Opener: x=-4, y=-4, w=808, h=608 New: x=4, y=4, w=610, h=450 If I then restore my old profile, then I suddenly get: New: x=0, y=0, w=800, h=600 which means that the old little window behavior is gone just after the profile switching. But the new case with a fresh profile is a bug, too, because the large window is not maximized. If I then, after running the test, open a new window with [Ctrl+N], then the new window is not maximized either as it should be. So even with a new profile, the bug still persists, and it appears that the testcase updates the user preferences, which it should not because the window is opened by a script not the user and the script does not even specify window dimensions.
Trust me, there are many ways to interpret what you just said. I'm uncertain, but you seem to be saying that the 808x608 Opener window in the new profile is not maximized. It really, really looks maximized. The terms "new case" and "large window" are also open to interpretation. Here's how it's supposed to work. I just tried this. Run Mozilla 1.7.1 in a new profile. (1) The first window it opens is sized (610x450) and positioned at (4,4). Did that not happen? That's just weird. With a new profile there's no saved state to make it behave any differently. (2) File Menu -> New Window opens a new window of the same size positoned at (26,26). (3) Close that new window, maximize the original window, open another new window. It should also be maximized. (4) When unmaximized, it should be at the same position and size as the restored state of the opener: (4,4) and (610x450). Behaviour in steps 3 and 4 may be contentious, but that's how it's supposed to behave and that's how it does for me with a new profile. (Note though that I'd swear in earlier testing I did when I wrote comment 7 that a maximized window could open an unmaximized one. It isn't supposed to. Is that what you're seeing? Simply that? If you could pin down how to make it happen repeatedly, we'd have us a bug.) Can you step through the exact same sequence and describe your results? If you do get different results, does it happen the same way every time? If it happens exactly as I described, then we're back to square two, still wondering exactly what setting is causing the problem, and indeed whether there is a problem.
There is a misunderstanding. Maximised in my case is 808*608. If the child window is then 800*600 then that is NOT maximized. That alone would be a seperate bug. There is definitely some weirdness being observed here. That did apparently only occur after the code changes that are mentioned in bug 240381. We have a pretty simple testcase here that reproduces on my end. And it reproduces on your end if I understand you correctly because you get 800*600 (non-maximised). I cannot produce more than what I did. Therefore I conclude that some QA testing may need to be started in context with the code changes of bug 240381. I have been involved in writing testcases for Mozilla for years, especially in the context of frames and new windows. Please believe me, I would not waste my time hunting a non-existing issue. It is definitely there, at least in my version. Please take a closer look. I can't get it to simply go away. Let me make an assumption (no proof here because out of scope): My initial result (mini window) morphed after some profile switching into a much smaller deviation (width 800 vs 806). It could well be that in combination with some other events, the effect gets accumulated such as that after a number of time new windows are opened, the new size gets more and more corrupted.
Now that I remember bug 230608, my confusion in comment 9 is cleared up and I'm back to believing there's no problem here. In Mozilla 1.7.1, a new browser window opened by a maximized browser window will generally itself be maximized. The exception is when the new browser window is not resizable. It's then opened restored (not maximized) at the restored size of the opener window. That's intentional (see bug 230608 (which is currently a restricted-access security bug, but trust me, the behaviour is intentional)). bht, if we assume that the restored size of the opener window in your original test was set very small for whatever reason, and that it is now for whatever reason set to your screen size, then everything is explained. The only question remaining is whether the restored size of the browser is shifting around underfoot for no good reason.
>If ... I run the testcase, then the new window is smaller and not maximized. It'll be not maximized, yes, but its size will be well defined: the restored size of the opener. >shifting around of the restored size of the browser >underfoot is an additional concern, but currently I don't have an idea how to >present a reproducible case for this. I could open a bug for [shifting restored >size of the browser window] just stating the observation. Such a bug would of course be unfixable without more information, but such placeholder bugs are important if for no reason other than organizing duplicates. This wouldn't be any of bug 169727, bug 209064, or bug 214106, would it? >This is a loss in functionality of window.open() that did not exist before this >bug. Therfore we cannot really close this bug, can we? It directly disagrees with with another, more important bug. That's what "Won't fix" is all about. If I've misunderstood our agreement on this matter, feel free to reopen. But it seems to me we have a handle on the problem and a label on the handle that reads "don't touch." I'm adjusting the summary to match our refined understanding of the bug.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WONTFIX
Summary: New window has wrong position, size. → resizable=no window with maximized opener isn't maximized
You need to log in before you can comment on or make changes to this bug.