176342 - windows opened using innerHeight/Width can open partially offscreen

Status: RESOLVED FIXED

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

Description

[Gérard Talbot]

Go to the given url and enter the following values:
screenX 300
screenY 300
outerWidth 300
outerHeight 300
sizeToContent() disabled checked
and select
titlebar, menubar, personalbar, toolbar, location, status, scrollbars

The content area of the generated popup window on a 800x600 scr. res. will not
be masked nor hidden nor cut off. On my monitor screen, I only see the statusbar
slightly cut off. On my monitor screen, the screenY of the generated popup gets
reset to 272 so that no part of the content area gets masked, hidden or cut off.
This is normal and expectable.

Now, close this popup and empty the outerWidth and outerHeight fields and input
300 for innerWidth and 300 for innerHeight and leave the other fields as before.
On my 800x600 monitor screen, I see 162 pixels of the generated popup window and
 138 pixels of the content area of the generated popup window are masked,
hidden, cut off. The screenY value is also/again 272.

[Actual results:] In other words, if the outerWidth/outerHeight values are not
known in advance, the browser seems to use the given values of
innerWidth/innerHeight to position the popup window. 
[Expected results:] I think the software should first determine the
outerWidth/outerHeight dimension values and then position the generated popup
window so that none of its content area gets masked, hidden or cut off.

This bug is more noticeable along the y axis mostly because the chrome elements
which might affect the issue of masking content area are along the y axis.

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

keyword: 4xp

It is not at all in the interest of the user to get a popup window being partly
masked or hidden. I even believe the status bar should never be masked.

XP Pro SP1 using build 2002102308 with a 800x600 resolution. Screen shots are
available if needed.

Comment 1

[Gérard Talbot]

This bug is best enlightened when a lot of chrome elements (menubar, toolbar,
personalbar, status) are requested in the popup. Because then, the difference
between the outerHeight and innerHeight values is more important, more easily
noticeable, therefore making the description of the bug more obvious.

I am able to reproduce this bug at any given screen resolution. This bug
behavior is so constant, regular that I could even figure out, anticipate,
predict accurately by how many pixels a popup window would/will be offscreen if
I was given values for the height of chrome bars.

In the description of this bugfile, when I mention "being partly
masked or hidden", I mean that no part of the content area of a popup window
should be OFFSCREEN, outside the browser viewport when such popup window
loads/has been loaded.

Comment 2

[Gérard Talbot]

The moveTo() documentation says:
" 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

Now, if a repositioning of a window prevents content area being offscreen,
partially masked, hidden, out of visual range, then an open() method call ought
to do the same as well. It is in the best interest of both [good-intentioned]
authors and users to have a full and complete view of a new secondary|child
opened window.

Comment 3

[Dan M]

I think perhaps I don't understand. Here's what I notice from the steps given in
the original comment. Position (screenX,screenY)=(300,300) is strictly followed.
Size (both inner and outer) seems to be strictly followed as well, with two
possible exceptions: the window is always a little wider (innerWidth 365) and
it's hard to be sure the outerHeight = 300 parameter is followed because the new
window's display of its own height is clipped at that size. However outerheight
of 400 works and the window verifies that. And my own testing with a more
compact new window size display suggests that outerHeight=300 works.

So I'm seeing this: the newly opened window is always a little wider than
requested and always opens at (screenX,screenY)=(300,300), even if that means
that it'll be partially offscreen on a small monitor. Additionally the contents
have no scrollbar, even if one is requested.

The new window's extra width is explained by minimum width requirements in the
chrome. The statusbar refuses to be narrower than that, so the window's width is
bumped up to match. The missing scrollbars is a problem, probably covered by bug
114850. (Sadly, this state seems to rock back and forth. I remember fixing the
opposite bug 130174.) Unless I'm missing something then, this bug is objecting
to Mozilla's willingness to place a window partially offscreen if it's opened at
an explicit position.

And you're probably right. It's probably more important to show as much as is
possible of a window's contents than it is to strictly adhere to the requested
position. In that case, this bug too will be taken care of by the patch in bug
162090. At first I argued against that bug, but I think it's going to happen now.

If I understood correctly, please confirm and mark this bug dependent on 162090.

Comment 4

[Gérard Talbot]

I do not understand what you are saying and to what values it applies. I'll
upload screen shots so that you can view exactly what I see. And follow exactly
the 2 sets of values I gave. I use a 800x600 scr. res.

Regarding scrollbars. One can edit scrollbars=yes in the window features list
argument but if the popup does not need scrollbars to display the content, then
the scrollbars will not appear: it acts like overflow:auto.

Partially offscreen in the case I submitted means 138px (out of 300 px) of the
content area are off the screen: that's 46%.

Again I want to underline that when outerWidth/outerHeight value(s) are given,
known, requested by the author, then Mozilla renders accordingly positions and
sizes. When the outerWidth/outerHeight are not specified but only width/height
or innerWidth/innerHeight values, and when there are a lot of chrome elements
requested, then Mozilla treats the width/height/innerWidth/innerHeight as if
they were outerWidth/outerHeight values (and this is incorrect). Even a comment
in the code suggests this:

1577       // This isn't strictly true but close enough
1578       winWidth = sizeSpecified ? (sizeChrome ? chromeCX : contentCX) : 100;
1579       winHeight = sizeSpecified ? (sizeChrome ? chromeCY : contentCY) : 100;

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

2 .pgn images coming up next

Comment 5

[Gérard Talbot]

Attachment: when outerWidth/outerHeight values are specified

By "using", comparing with the background grid image, you can see that all
values are respected. Mozilla "vetoed" over the screenY=300 coordinate and
re-position the popup window to 272. We can see that the taskbar of the popup
window is sliced, cut off; that's a very minor problem. 

This image show a rather well rendered, an accordingly rendered popup window. 

The next image will show the bug as described in this bugfile.

Comment 6

[Gérard Talbot]

Attachment: When outerWidth/outerHeight values are NOT specified, when innerWidth/innerHeight values only are specified

Here, screenX and screenY are the same as the previous image.

Here we see only 162px of content area. Just by looking at the xul:thumb (the
scrollbar), you can deduce that there is only a little of content still
scrollable at the bottom and that the scrollbar is long. In fact the whole
content area of the popup is exactly 300px: so there is actually exactly and
precisely 138 pixels of the content area which is offscreen, under the window
taskbar and even beyond further lower than the taskbar. Here are the values
that the image of the popup window do not show:

innerWidth: 300
innerHeight: 300
outerWidth: 306
outerHeight: 458

The expected results should have been to move this popup further up, 138px up
in the user screen. So, the screenY would have been 272 - 138 = 134 insuring
that no part of the content area is off the screen (only maybe the taskbar of
the popup window).

Comment 7

[Dan M]

  OK, it turns out I don't get a vertical scrollbar on your test page only if
I've requested a statusbar. (And if I have the "allow scripts to hide the
statusbar" pref turned off, there's pretty much always a statusbar.) Something's
strange there. But since that's not what you're concerned about, onward.
  Oh. You're saying that a newly opened window's requested position *is*
adjusted to fit the whole thing onscreen. But the position adjustment is made as
if the newly opened window's requested size were its outer size, even if it was
given an inner size. So to be specific, a window opened with an outerHeight of
300 and a screenY of say 10000 is pushed up to around (screenheight - 300), and
that's nice. But a newly opened window with a requested innerHeight of 300 is
positioned at the same place, (screenHeight - 300), and so it's clipped
offscreen because it'll be taller than that.
  Yes? Alright, that's troublesome.

Comment 8

[Gérard Talbot]

> You're saying that a newly opened window's requested position *is* adjusted to
fit the whole thing onscreen.
Yes, it should according to documentations and references. And empirically, that
is what I often/usually see.

> But the position adjustment is made as if the newly opened window's requested
size were its outer size, even if it was given an inner size.
Yes, it looks like this is the case. And I'm pretty sure I found the spot where
the code "makes", goes for such shortcut.

> a window opened with an outerHeight of 300 and a screenY of say 10000 is
pushed up to around (screenheight - 300)
Mozilla should re-position the popup window to a screenY value of
screen.availHeight - 300 
(so that no part of chrome - like the statusbar - or content area are masked by
the windows task bar or any other semi-permanent os-dependent applications).

> But a newly opened window with a requested innerHeight of 300 is
positioned at the same place, (screenHeight - 300), and so it's clipped
offscreen because it'll be taller than that.
Yes. That is what I discovered and what I see. That is what the uploaded images
show. And that is what the code "short-cut" or approximation suggests. 

Comment 9

[Gérard Talbot]

> But the position adjustment is made as if the newly opened window's requested
size were its outer size, even if it was given an inner size.
Exactly. This is exactly the problem with this bug. When outer values are given,
the adjustement made is correct. When inner values are given, the code treats
these as if they were outer values: that way, the code execution saves time but
then if a position adjustement needs to be done, then it will be offset by the
height of requested chrome elements.
The bug behavior is more easily noticeable when the top/screenY value is big
(giving the window less space to work with) and when a lot of chrome elements
are requested. The total size amount of chrome elements can go over 200 pixels,
regardless of screen resolution:
- titlebar
- menubar
- toolbar + location bar (Navigation toolbar)
- personalbar (directories)
- Site Navigation Bar
- Tab bar
- Prefs bar 
- status bar
- window [re-]sizing borders/handles (2px each)
So a popup window can be wrongly offset and be off-screen by as much as 200 px.
I have tested and verified this on several resolutions. I can upload screen shots.

----------

1579       winHeight = sizeSpecified ? (sizeChrome ? chromeCY : contentCY) : 100;

If sizeChrome is true then use the requested outerHeight value otherwise use the
requested contentHeight (innerHeight or height) value: this where things are wrong.

Comment 10

[Dan M]

Got it. Windows opened to a size specified using innerHeight or innerWidth
aren't properly constrained to fit entirely onscreen. It's a security issue
because part of a window's contents are effectively invisible (though not really
hidden; it's easy enough to see that the window isn't completely on-screen.)
This is my bug. Taking from Johnny. Can't promise a milestone on it just yet I'm
afraid.

Comment 11

[Gérard Talbot]

3 other items can make a popup window get offscreen even further, at least for
Window XP users.

Start/Settings/Control Panel/Display/Appearance tab/Advanced button/Item: 
and here pick
- Active Title Bar
- Active Window Border
and increase their sizes and these chrome UI elements will furthermore increase
the differential between inner* and outer* values.

Setting innerWidth/innerHeight values of a popup in window.open() to
screen.availWidth/screen.availHeight or to screen.width/screen.height values
when there are semi-permanent os-dependent applications will (or can) make a
bigger part of a popup being masked, clipped, hidden, get under these
os-dependent applications. Mozilla application now considers the dimensions of
workarea (at least in a static manner - bug 162090) but window.open-ed popups
still do NOT consider dimension values of screen.availWidth and
screen.availHeight as strict limitations/borderlines to their sizes.

Such popup windows can be within the screen but, at the same time, clipped,
partly hidden, partly off the workarea, overflowing the workarea.

Comment 12

[Christopher Hoess (gone)]

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

Comment 13

[Dan M]

A patch in bug 239876 fixes this bug.

Comment 14

[Dan M]

Fixed by patch in bug 239876.

Comment 15

[Gérard Talbot]

The window no longer opens offscreen: so, this bug is fixed. Mozilla 1.8a build
2004042909 XP Pro here.

But the statusbar of the popup window can still be clipped even though it should
not. Mozilla seems to give a minimal innerHeight of 150 and then starts allocate
the vertical space to the statusbar. I'll open another bugfile showing this.