When using expanded system bar at bottom of screen, Mozilla window is partially obscured behind system bar. This also obscures any horizontal scroll bar that might be at bottom on window within main window. Makes for difficulty in reading even the Bugzilla pages. Same problem may exist for system bar in other locations.

Reporter: could you please read the Bug Writing Guidelines at http://www.mozilla.org/quality/bug-writing-guidelines.html to see the kinds of information we need in a bug report. Please report back with more information (like BuildID and steps to reproduce) after reading those guidelines and consider using the Bugzilla Helper to report future bugs. The Helper can be found at http://www.mozilla.org/quality/help/bug-form.html Thanks for your help in testing Mozilla.

Wesha: are you trying to avoid people from reporing any more bugs? Please be polite and just ask for the details - without any reference to the bugwriting guide. Nicholas Sturm: you mean the auto-hiding windows taskbar? Well, that thing appears over any window, so this would be invalid. Don't move the mouse to far down ;)

Is this really a Mozilla bug? Don't all apps get partially obscured by this bar?

You are correct. When I got to the word "clue" I went to read that. It did not lead me back to the "how to" page. BUILD # 2002053012 does not hide the bottom of the window. Unfortunately with side-bar closed I cannot coax the handle to appear to open the sidebar, but that would be a new problem and I've resolved not to bother you with any more observations. Bye.

Now that I look at this, I think the bug should read "Mozilla is obsured by task bar when window is maximized". Does this accurately reflect the problem you're experiencing? When a window is not maximized, it can be obscured by the task bar, or the edge of the screen for that matter, because you can move it anywhere you want. That said, when the window is maximized it shouldn't make itself larger than the available viewing area. I have auto-hiding off on my system, and I am seeing the problem too.

don't see a bug here. Reporter, you have described Mozilla's current behavior, now can you describe the "expected" behavior? Also, look at the taskbar properties dialog (rite click on the taskbar). Is it set to be the topmost window?

On initial observation the obscuring occurred. Subsequent attempt did not show the observed behavior, i.e., when window expanded to maximum it observed the location of system bar and avoided obstruction. I have been informed browser window commonly becomes obscured when not maximized and shiften (moved) past any limiting object that could cover it. I now presume the window was not quite maximum and inadvertently was moved resulting in the obstruction. I had moved the separating bar between frames and could have thus moved a non-maximum window making it "not-obvious" how the bottom of right window pane could be moved to show all of the vertical scroll bar. I cannot reproduce the problem *except* when the main frame is less than maximized so you may reject the bug report if you desire.

getting this bug off the unconfirmed radar. Reporter, reopen this bug if you can reproduce this again.

Apparently we don't observe SPI_GETWORKAREA unless we're maximized. Should we be?

I now see that both IE and Microsoft Word respect the SPI_GETWORKAREA settings when opening a new window, whether they're maximized or not.

it's required by ms :)

Funny, it doesn't appear that notepad respects that setting -- but I don't have a copy of XP yet.

Quoted from the microsoft windows logo site that timeless linked to: > SPI_GETWORKAREA: > Sets the primary display monitor work area size. > Assistive technology products, such as a magnification utility, may adjust the > work area available to your application. At no time should your application > appear behind the magnification window or behind a docked task bar. Use the > Magnifier utility to determine if your application has a problem with this > setting. This makes it sound like the app should always contrain itself to the work area. Strange, MSWord is onl;y contraining itself when I open a new window or restart, at least in Win2k. Anyone have XP?

First of all, widget/src/windows/nsWindow.cpp's ConstrainPosition() has some bad bugs in the formula where the allowSlop work is done. Second, the method is seriously limited in what it can do, because it can't constrain the width or height of the window. This causes a problem when the window is too large for the working area. Marking section 508 because this makes us interfere with Magnify, which is an accessibilty feature of the Windows platform.

This fixes nsWindow::ContstrainPosition() so that it makes sure the window fits within the SPI_GETWORKAREA part of the screen. It still takes the PRBool aAllowSlop argument (20 pixels), which means the window can be 20 pixels offscreen in any direction. I have no idea why this slop is useful -- in fact, it makes it much more difficult to close, minimize, maximize, move or resize the window when the window edges are offscreen. Also fixes some major logic errors in widget/src/windows/nsWindow.cpp's ConstrainPosition(). The calculations were completely wrong - here mBounds.width is being used with screenRect.left, when it needs to be moved down to the lines with screenRect.right: - if (*aX < screenRect.left - mBounds.width + kWindowPositionSlop) - *aX = screenRect.left - mBounds.width + kWindowPositionSlop; - else if (*aX >= screenRect.right - kWindowPositionSlop) - *aX = screenRect.right - kWindowPositionSlop; I haven't checked through the other ConstrainPosition methods for the same problems; I probably should. Seeking feedback, on why we should allow window slop, and whether it's okay to modify ConstrainPosition() to change window width/height.

Comment on attachment 102682 [details] [diff] [review] 102681: Patch #1 -- Change nsIWidget::ConstrainPosition() so that it takes inout width & height params 1) I disagree that there are major errors in the logic of ConstrainPosition. I believe you're assuming the intent is to allow a window to bleed a bit off the edge of the screen. In fact the intent is to prevent a window from being placed completely offscreen. When constraining a window being moved by untrusted script, it should be forced completely onscreen; no slop. But that's taken care of elsewhere (sadly, the code is duplicated and not well.) When restoring a window's position to the last position set by the user, it should go where the user put it. If the user placed it partly offscreen, we're in no position to argue. If the persistence data are corrupt or the screen geometry has changed, we should however make certain the window isn't completely unfindable. That's what nsIWidget::ConstrainPosition does. 2) Why add size parameters to the method? The window's size is known at the time the method is called, or should be. Is that the bug, then? Comment 7: "I cannot reproduce the problem *except* when the main frame is less than maximized". I guess I don't quite understand the problem. It sounds like a window can be sized really large -- not maximized -- then moved to partially obscure thngs. Doesn't seem like a problem. If the window is to be maximized, it'll be constrained to the work area by the maximization code. If not, the window's size should be known at the time ConstrainPosition is called. 3) If you do end up needing to add size parameters to the method, please take a shot at filling in their implementations on the other platforms. At a minimum, put in NS_WARNINGS. Wouldn't want the other platforms to fall out of step. Welcome to the wonderful world of XP coding, behind the XP facade! In summary, I don't get it. What's the problem? Comment 5: is it just that the maximization code is missing some check it shouldn't?

Dan, the problem is not with maximized windows. It's that newly created windows can be outside the work area. A good way to see the bug is to run magnify.exe (which lets you drag and dock to different sides of the screen), and then open new windows. I will of course fix all of the platforms with ContstainPosition() impl's in the next patch -- I just wanted to seek feedback before continuing with the approach.

> 1) I disagree that there are major errors in the logic of ConstrainPosition. Okay, I understand what this does now. However, this is counter to what Microsoft says here: > At no time should your application > appear behind the magnification window or behind a docked task bar. Sure, we should allow the user to move or resize the window wherever they want. That's what MS does too. However, when opening a new window I think we should make sure it's completely visible. Perhaps we should not use allowSlop = TRUE on new window opens, just on resize.

I've figured out what this bug needs. An explicit description of the problem. I've got email going with Aaron, hopefully some specific steps to recreate the problems he's seeing are on their way. However as this bug stands, the only verifiable complaint I can see is the original one: (1) (a) Place the bottom of Mozilla's browser window near the top of the Windows taskbar, which itself is positioned at the bottom of the screen. (b) Exit Mozilla. (c) Expand the taskbar upward. (d) Launch Mozilla. The bottom of its window underlaps the expanded taskbar at the bottom of the screen. However note: (2) (a) Do 1a. (b) Expand the taskbar to overlap the bottom edge of Mozilla's window. Windows resizes Mozilla's window to not intersect the taskbar. I don't see how (1) is any different from (3) (a) Move Mozilla's window down so that the bottom edge is offscreen. (b) Quit, relaunch. The bottom edge of Mozilla's first window is offscreen. Oh! *That's* why you want to add size parameters to ConstrainPosition: in case the window doesn't fit entirely onscreen. Guys, I don't think this is a bug. See case (3). This is only going to happen if you change your screen geometry while Mozilla isn't running. That should happen very rarely. How often do you change your screen geometry? Any potential fix would conflict with the desire to allow a user to position the window partway offscreen. I should think this would be much more common. Maybe the user wants to drag Mozilla mostly out of sight toward the bottom but wants to be able to drag it back onscreen, whole, later. Maybe he doesn't want the window to be scrunched to fit onscreen. I don't want to do it automatically. I think this is not a bug. Finger hovering over the won't fix button...

danm, whether or not the api is at issue, we need to honor magnify.exe docking, or the taskbar becoming always ontop or the taskbar growing. as of 10/03-08 we don't honor any of those (w2k). the following honor all of these: cmd.exe acrobat reader 5 magnify's dialog :) taskmanager notepad winzip8 explorer

well, err. at least sometimes it didn't honor it. i'll have to try and find better steps and descriptions :(

Normally the screen geometry won't change often, but in Windows (from at least 9x on), accessibility aids can change the allowed viewport to reserve parts of the screen for their own use. The function SystemParametersInfo lets you limit what is supposed to be valid window space, which can be equivalent to a temporary change in the screen geometry. The SPI_SETWORKAREA and SPI_GETWORKAREA options control it. One of the built-in Windows XP utilities that uses this function is the magnifier brought up by Windows+U and then turn on Magnifier with the dialog that gets presented. If Magnifier was turned on before Mozilla started a window could overlap magnifier.

Alright I get it now. I still don't see what the problem is. timeless (comment 21): As far as I can tell, we honour screen size/position changes including magnify docking. If Mozilla is running, the OS takes care of it for us. If not, next time Mozilla launches it makes sure at least part of the window is visible. This is old behaviour. We made a conscious decision to make it work this way in the year 2000. But OK, tell me we're breaking some user interface guideline or windows showing up partially offscreen is an accessibility issue and I'll cave. It's not such a great feature I need to defend it to death. If you decide to change this, see the attached patch. It'll do what you want and it's much simpler than the previous one.

bug 130916 has a good argument for forcing windows completely on-screen. OSX windows can be dragged only by their titlebar.

Dan, because of the OSX situation you point out, and problems in Windows with accessibility aids like Magnify, I don't think we should allow slop on new window creation. I think we should continue to allow it when the user is moving or sizing the current window.

Yeah, I'm convinced. Do this thing.

My question now is, do we still need the aAllowSlack parameter, or should we get rid of it. It doesn't look like we ned it since we don't call ConstrainPosition after a move/resize from the user.

Comment on attachment 103212 [details] [diff] [review] constrain new windows to be completely onscreen r=aaronl Seeking sr=

Comment on attachment 103212 [details] [diff] [review] constrain new windows to be completely onscreen sr=jst

Note that the first two hunks of that last patch have already been checked in because of other bugs. Only the @@ -966,6 +966,24 @@ chunk is still wanting. Note also I've run across a bug (no, I can't find it now) in which someone commented they really liked the ability to leave windows partially offscreen and wanted this to be configurable as a preference. I'm not arguing for that myself. Just saying. Somebody likes everything.

1- How can we know if the patch of attachment 103212 [details] [diff] [review] landed in the trunk? 2- I wish better identifiers would be used in the patch. In the DHTML object model that Mozilla applies, screen has 4 properties referring to 4 distinct, separate measurements: width, availWidth, height and availHeight. I believe this wording of identifiers would help eliminate potential confusion: + PRInt32 screenAvailWidth; + PRInt32 screenAvailHeight; + screen->GetAvailWidth(&screenAvailWidth); + screen->GetAvailHeight(&screenAvailHeight); + if (specWidth > screenAvailWidth) + specWidth = screenAvailWidth; + if (specHeight > screenAvailHeight) + specHeight = screenAvailHeight; etc... 3- Right now (Moz1.2.1 build 20021130), the screen.availLeft, screen.availTop, screen.availWidth and screen.availHeight properties are NOT updated in real time. MSIE 6 for windows and Opera 7 beta 1b (build 2349) update the screen.availWidth and screen.availHeight property values in real time. Demo case coming up.

This demo case will work for MSIE 6 for Windows and Opera 7 beta 1: note that these browsers will update in real time the screen.availWidth and screen.availHeight property values thanks to an resize event type on the window or document object. Mozilla 1.2.1 does not update in real time all of the screen.avail* property values: these properties are the coordinates and dimensions of the WORKAREA for the browser application. This was also implicitly explained in bug 55868. More details, instructions are given in the demo case.

If you want to report a separate bug for dynamic resizing issues, go ahead. This bug is for new windows.

MSIE's "WORKAREA" can be efficiently translated as screen.availLeft, screen.availTop, screen.availWidth and screen.availHeight properties in Mozilla's code. Such WORKAREA needs 1 coordinate (relative to top-left corner of the user screen) and 2 dimensions. Now, if screen.availTop just changed because the user opened MS-Magnifier or an os-dependent application (say MS-Office bar) and docked it on the left or right hand side, then the correspondent coordinate and dimensions should be updated in real time. My demo demonstrates that this is not the case. Note that all these 4 screen.avail* properties were already in NS 4.0 PR1 and higher; so, we're not inventing anything new here. I'll file another bug anyway on the resizing issue. Is it too late to use better identifiers in the patch?

I'm personally satisfied with the identifiers in the current patch -- and more importantly, it has sr= now. I just don't want to spend more time jumping through all the hoops and asking a superreviewer for more of their time, to change variable names. You can always submit a new patch yourself and request reviews.

I filed bug 184459. On the time issue, I think you're wrong. My experience has often taught me that when confusion is involved in a code, then a lot more time is later spent by others to overcome confusion in the code. More time than it would have taken to deal with it in the first place. The gamble is always on "wasting" time now or potentially wasting a lot more time later. In a project of this magnitude, proper wording and meaningful, clear, unambiguous identifiers is not negligeable nor a luxury with many [new] people coming from different fields/expertise, trying to understand each other well. I know at least a dozen bugfiles which were evnetually invalidated or wontfix-ed just because of a misunderstanding. Just my 2 cents regards

fixed, thanks Danm

Don't have a nightly to check with at the moment, so this is as much for myself as anyone else, but it looks like this may have resolved bug 181980 as well, but I'm not clear what happened with the "slack" thingy. has this fixed the case where some script resizes the window to be "maximized" size, with the borders just off the screen?

I'm asking that this bug be REOPENED . When creating a popup window with window.open(), screenX, screenY, top and left values of the windowFeatures argument list will be relative to the whole screen coordinates, not relative to the (0,0) coordinates of the workarea. This happens even when the workarea has been first set, defined prior to/before opening the Mozilla application. There is a similar problem with innerWidth, width, outerWidth, innerHeight, height and outerHeight values of the windowFeatures argument list. Corrective adjustements to requested dimensions (inner or outer ones) will be relative to screen.width/screen.height, not relative to screen.availWidth/screen.availHeight. Corrective adjustements to requested dimensions (inner or outer ones) will be triggered when screen.width/screen.height are insufficient to render the whole requested dimensions of a popup when, in fact, screen.availWidth and screen.availHeight dimension values should be the limitations, the maximal values for [outerWidth and outerHeight values of] a popup window. Popup window dimensions and positions are not constrained within the workarea as they opened [partly or entirely] underneath, underlapped os-dependent applications. I can upload testcases along with step-by-step instructions to reproduce, explanations, screenshots. I can also open another distinct separate bugfile for this since it's clearly related to window.open() method. XP Pro SP1, build 2003012804.