Closed Bug 118717 Opened 19 years ago Closed 17 years ago
Never let sites position windows outside the screen
An example would be that the window is so large that the button for closing is outside the window, which makes it harder to close it. But usually I think it happens by pure ignorance. BTW: Typo in summary: position
Summary: Never let sites piosition windows outside the screen → Never let sites position windows outside the screen
Dan, you still doing window.open stuff? Changing component. Not really event handling.
Assignee: joki → danm
Component: Event Handling → XP Toolkit/Widgets
You might want to consider bug#84754 as a part of this... It at least lists a possible exploit of this bug
*** Bug 148518 has been marked as a duplicate of this bug. ***
If you decide to implement this, then add a pref for it (even make it default), because I currently have some windows partly outside the screen. Once I had to run a program under win, which only let me position it inside the screen (in always on top mode...), and it killed my productivity very much. I know this bug is about automatic positioning, but I use it for my start page, and need this _as a (power) user_.
http://infomanager1.consors.de:9032/consors/formswitch3?searchfor=yahoo&searchforicat=alle Click on any link in the left column. Depending on your screen size the popup window is taller than the screen. pi
Jesse, I just filed this bug based on a comment of "pi" in another bug.
Looks like I cannot get a small window move out of the screen anymore. It happens only if window is larger. This is bug 104303 then. pi (no need for quotes, it's in my passport;-)
Previous comment was based on Linux: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020701 There the larger window is aligned top left, but exceeds the screen. The second window opens aligned bottom right, but fully on screen. For Windows (Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1a+) Gecko/2002070404) the first opens somewhere in den middle of the screen, the second as set, i.e. not on screen even though there is enough room. pi
How about the target milestone? pi
Any hope? What about the target milestone? pi
Update target milestone to 'Future' since this missed the 'mozilla1.1beta' train.
Target Milestone: mozilla1.1beta → Future
I can explain the off-the-screen behavior of both generated popups in attachment 90215. First of all, this bug and the given testcase fit perfectly and exactly bug 176342. First link example: "Very large window like in bug 104303" of the testcase attachment 90215 [details]. With such requested dimensions, there is an adjustement made by the code but we all see that such dimension adjustement is wrong...as we see chrome with/without content of the generated popup being off the screen. The first error in the code is to consider the value screen.width and screen.height as the correct values for comparing requested width/height for the popup when it should be screen.availWidth and screen.availHeight so that semi-permanent os-dependent elements/applications such as Windows taskbar may be considered. Since it is not considered, the popup adjustement code "misses" by an additional length corresponding to the height of the actual, current Windows taskbar. The other element is the wrong assumption that in case outerDimensions are not specified, then use, take the specified innerDimensions. So, the offset, the length of the off-the-screen will be greater as there are more chrome bars requested in the open() call. Finally, when top/left/screenX/screenY are not specified, the code uses the coordinates of the last non-maximized window. Knowing exactly what are the coordinates of the last non-maximized window will also help determine in advance by how much the generated popup window will be offset off the screen. For a reason I do not understand, the code never overrules, overrides the coordinates of the last non-maximized window when determining the final position of the generated popup window when requirements should force so. This suggests a missing detail in the code, at least regarding the best place to branch the code to make position adjustements. ---------------- Second link example: "Window tries to open (partially) outside the screen" of the testcase attachment 90215 [details]. There is a 8 pixels offset along the x-axis, which is equal to the width of window [re-]sizing borders/handles (2*4px). The visible part of the generated popup window is 200px wide and 100px in height. So there is no bug with that. The problem is that when outerWidth and outerHeight values are not specified in the window.open call, the code will then assume, consider the specified width (or innerWidth) and height (or innerHeight) as if these were outerWidth and outerHeight values for positioning purposes. And the more a popup window has chrome elements along the y-axis, the more chrome with/without content of the generated popup will be off the screen. Here, in the given example of attachment 90215, you can precisely assess that the part (chrome with/without content) of the generated popup window which will be off the screen will be equal to the differential between outerHeight and innerHeight. And in that testcase, that means titlebar height plus 2* height of window [re-]sizing borders/handles. I verified empirically this very carefully; I even spotted the exact place where the code makes wrongly the approximation that outerDimensions = specified innerContentDimensions. I think there are exactly 3 distinct separate bugs being present, active in attachment 90215 [details].
Re Comment #6: >do you have a testcase that shows web pages being able to position a window off the screen or partially off the screen? http://bugzilla.mozilla.org/attachment.cgi?id=110263&action=view also bug 176342
/!\ Mozdev multizilla toolbar disappear of the popup window
Re Comment #6: >do you have a testcase that shows web pages being able to position a window off the screen or partially off the screen? Bug 183633
Depends on: 183633
Fixed by patch in bug 239876.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.8alpha
*** Bug 255388 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.