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.
Summary: Content area of popup window should not be hidden, masked, cut off → No part of the content area of popup window should not be masked, offscreen when it loads.
Summary: No part of the content area of popup window should not be masked, offscreen when it loads. → No part of the content area of a popup window should be masked or offscreen.
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.
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
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.
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).
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.
> 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.
> 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.
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.
Assignee: jst → danm
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: No part of the content area of a popup window should be masked or offscreen. → windows opened using innerHeight/Width can open partially offscreen
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.
*** Bug 190936 has been marked as a duplicate of this bug. ***
Fixed by patch in bug 239876.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8alpha
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.
You need to log in before you can comment on or make changes to this bug.