Gérard Talbot Reporter
	Description • 22 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130

When sizes/dimensions are not specified in a window.open() call, then the
applied sizes/dimensions to a popup generated with window.open() call come from
the stored, recorded outerWidth and outerHeight values of the last non-maximized
window. So far, so good. The problem arises when the specified requested
screenX/left and/or screenY/top plus these stored, recorded window dimension
values are going to position the popup off the screen: a normal adjustement,
position correction should happen but it does not.

XP Pro SP1, Mozilla 1.2.1 (20021130) here.


Reproducible: Always

Steps to Reproduce:
Steps to reproduce (assuming a 1024x768 scr. resolution):
1- Go to the given URL
2- open a popup, any popup and then resize its outerWidth/outerHeight values to
900 outerWidth and 500 outerHeight
3- close that popup
4- Enter the following values in the form:
left: 600   top: 500
and check a few toolbar checkboxes, say, the checkboxes
titlebar , menubar , toolbar , location , status , scrollbars
(Important: all sizes, dimensions input fields MUST be blank, empty)
5- Click the "Create a popup window ..." button


Actual Results:  

Actual results:
The screenX value of the popup window will be 600
The screenY value of the popup window will be 500
A large part (more than 66%) of the popup window will off the screen, both along
the x-axis and the y-axis

Expected Results:  

Expected results:
The screenX value of the popup window should be 600 + 900 - 1024
The screenY value of the popup window should be 500 + 500 - 768 + 28 

----------------------------
28 is the height of the Window taskbar; the value - 768 + 28 should equal to
minus screen.availHeight


This bugfile is in fact a sub-part of bug 118717, more clearly pinpointed,
explicitly defined.

References:
http://developer.netscape.com/docs/technote/javascript/window/images/display_screen.gif

http://lxr.mozilla.org/seamonkey/source/embedding/components/windowwatcher/src/nsWindowWatcher.cpp#1570

"Security: Exceeding any of the boundaries of the screen (to hide some or all of
a window) requires signed JavaScript, so a window won't move past the screen
boundaries."
found at
http://developer.netscape.com/docs/manuals/js/client/jsref/window.htm#1202631

	Gérard Talbot Reporter
	Comment 1 • 22 years ago

I figured it out. When width and height (inner or outer - does not matter here)
dimension values are not defined, then the persistent data is used (previous
width and height of last non-maximized values) but the correction done to
position (screenX/screenY) assumes that the width and height are 100.
So, I can create a popup window which will be positioned at (924,640) and this
regardless of the size of the window.
924 = 1024 (screen.availWidth) - 100;
and 
640 = 740 (screen.availHeight) - 100;
These values comes from a scr. res. of 1024x768 where the Windows taskbar uses
28 pixels.

Here's again steps to reproduce on a 1024x768 scr. res.:
1- Go to the given url and input outerWidth:900 and outerHeight:500
2- Create the popup
3- Close the popup
4- Clear and reset the form
5- input left:924 and top:640 (make sure no width and no height values are input)

Actual results:
a 1007x709 popup window appears and its left-top corner is at (924,640)
precisely. So, an area representing 907x609 is totally off the screen, not
within the visual scope of the screen.

Expected results:
a 900x500 popup window should appear and be positioned at
screenX = 1024 - 924
screenY = 740 - 640

and the pseudo-code to determine these coordinates is:

if((requestedPositionX + StoredOuterWidth) > screen.availWidth)
then correctedPositionX = screen.availWidth - StoredOuterWidth

if((requestedPositionY + StoredOuterHeight) > screen.availHeight)
then correctedPositionY = screen.availHeight - StoredOuterHeight

Where did the 1007 and 709 values come from? They came from the previously
stored screenX and screenY values of the last non-maximized window in this
calculation:

screen.availWidth - StoredScreenX = outerWidth (1007) of the next window with
undefined, unspecified width (inner or outer - does not matter here) value.

screen.availHeight - StoredScreenY = outerHeight (709) of the next window with
undefined, unspecified height (inner or outer - does not matter here) value.

The behavior explained above is 100% reliable, reproducible and predictable;
screenX and screenY coordinates of the second window are predictable in advance
if the other 2 data are given.

	Gérard Talbot Reporter
	Comment 2 • 22 years ago

Here's a 100% convincing, overwhelming demonstration of all explanations given
so far. Seeing, viewing, testing this test case will facilitate understanding
of explanations given so far.

This test case clearly demonstrate that the code is not robust enough to take
into consideration special cases (like undefined dimension size values).

The test case could be improved to store, keep track of persistent data (top
and left values) and to output them in the window. The content of the popup
window could be customize at will (with, say, a background measurement grid
image).

Finally, the test case demonstrate that the problem is worse, can be worse when
more chrome bars are present: this underlines for the nth time that, at some
point in the code, outerDimension values are approximated as innerDimension
values. (see end of http://bugzilla.mozilla.org/show_bug.cgi?id=176342#c4 )

I think this test case cannot be further reduced. I think this test case
exemplifies, pinpoints the external behavior of many other already bugfiles.
I chose to use outerDimensions in this demo but one could have used the
cross-browser compatible width and height and then see how the other browsers
handle this extreme test case.

	Johnny Stenback (:jst)
	Comment 3 • 22 years ago

danm agreed to have a look at this bug, reassgning, and confirming.

	Dan M Assignee
	Comment 4 • 21 years ago

Fixed by patch in bug 239876.

	Gérard Talbot Reporter
	Comment 5 • 21 years ago

I tried the testcase with Mozilla 1.8a build 2004042909 under XP Pro and I got
the expected results. Congratulations Dan, thank you very much; this fix is
greatly appreciated! :)