118717 - Never let sites position windows outside the screen

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Ben Bucksch (:BenB)]

<quote src="http://bugzilla.mozilla.org/show_bug.cgi?id=86284#c3"
       author="Boris 'pi' Piwinger">
Opening a new windows with JavaScript also can position the window. This
sometimes happens such that not all of the window actually is on the screen. So
I have to move the window by hand, even if there would have been enough space in
the first place. This should not happen.

The same holds for opening windows which do not fit the screen.
</quote>

For windows opened by sites:
- Windows should never be larger than the screen
- If part of the window would be outside the screen,
  change the position so that is no longer true.

"Screen" here means the current screen, if the user has several monitors.

This bug might be abused by hostile/evil sites, but I couldn't figure out a
concrete example.

Comment 1

[Boris 'pi' Piwinger]

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

Comment 2

[joki (gone)]

Dan, you still doing window.open stuff?

Changing component.  Not really event handling.

Comment 3

[extremely]

You might want to consider bug#84754 as a part of this... It at least lists a
possible exploit of this bug

Comment 4

[Boris 'pi' Piwinger]

*** Bug 148518 has been marked as a duplicate of this bug. ***

Comment 5

[bugs]

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

Comment 6

[Jesse Ruderman]

BenB, do you have a testcase that shows web pages being able to position a
window off the screen or partially off the screen?  According to
http://www.mozilla.org/projects/security/components/signed-scripts.html,
Mozilla's policy is to disallow that except for privileged scripts.

Two known cases:
bug 104303 script can make a window larger than the screen (Linux).
bug 103454 Javascript allows site to hide windowmanager window decorations.

[e-mail]: You can give your start page the ability to resize itself to any
geometry by putting it at a file:/// url and adding a call to
netscape.security.PrivilegeManager.enablePrivilege with (I think)
"UniversalBrowserWrite" just before it calls resizeTo().  There's no need for a
pref.

Comment 7

[Boris 'pi' Piwinger]

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

Comment 8

[Ben Bucksch (:BenB)]

Jesse, I just filed this bug based on a comment of "pi" in another bug.

Comment 9

[Boris 'pi' Piwinger]

Attachment: Testcase

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;-)

Comment 10

[Boris 'pi' Piwinger]

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

Comment 11

[Boris 'pi' Piwinger]

How about the target milestone?

pi

Comment 12

[Boris 'pi' Piwinger]

Any hope? What about the target milestone?

pi

Comment 13

[Juan José Mata]

Update target milestone to 'Future' since this missed the 'mozilla1.1beta' train.

Comment 14

[Gérard Talbot]

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

Comment 15

[Gérard Talbot]

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

Comment 16

[Yves Lambert]

/!\ Mozdev multizilla toolbar disappear of the popup window

Comment 17

[Gérard Talbot]

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

Comment 18

[Dan M]

Fixed by patch in bug 239876.

Comment 19

[Robert Parenton]

*** Bug 255388 has been marked as a duplicate of this bug. ***