Closed Bug 183633 Opened 22 years ago Closed 21 years ago

screenX/left and screenY/top of popups are not corrected accordingly when sizes are not specified

Categories

(Core :: DOM: Core & HTML, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.7final

People

(Reporter: bugzilla, Assigned: danm.moz)

References

()

Details

(Keywords: dom0, testcase)

Attachments

(1 file)

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
Keywords: 4xp, dom0
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.
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.
Keywords: testcase
danm agreed to have a look at this bug, reassgning, and confirming.
Assignee: jst → danm
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 118717
Blocks: useragent
Depends on: 239876
Fixed by patch in bug 239876.
Target Milestone: --- → mozilla1.8alpha
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
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! :)
Target Milestone: mozilla1.8alpha → mozilla1.7final
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: