254756 - resizable=no window with maximized opener isn't maximized

Status: RESOLVED WONTFIX

(SeaMonkey :: General, defect)

Description

[bht237]

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

Comment 1

[bht237]

Attachment: TEstcase

Comment 2

[Dan M]

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.

Comment 3

[bht237]

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.

Comment 4

[Hermann Schwab]

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

Comment 5

[Dan M]

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.

Comment 6

[bht237]

Attachment: 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.

Comment 7

[Dan M]

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.

Comment 8

[bht237]

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.

Comment 9

[Dan M]

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.

Comment 10

[bht237]

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.

Comment 11

[Dan M]

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.

Comment 12

[bht237]

Dan, what you are saying makes 100% sense to me, so there is no misunderstanding
there. According to your analysis, it is not possible to let JavaScript open a
non-resizable, maximized window even if the restored size of the browser is full
screen AND maximized AND if the opener is maximized.
In other words if my restored size is full screen and maximized, then every
window I open manually is also full screen and maximized. If under these
conditions I run the testcase, then the new window is smaller and not maximized.

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? I think we have outlined
the rules of what was is expected clearly so that these rules could be
incorporated into any new code.

I agree with you that 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 it just stating the
observation and adding the image but do you think that would have a value?

Comment 13

[Dan M]

>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.