Closed Bug 162090 Opened 22 years ago Closed 22 years ago

Mozilla not respecting SPI_GETWORKAREA when positioning new window

Categories

(Core :: Disability Access APIs, defect, P1)

Product:
Core
Component:
Disability Access APIs
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.3alpha

People

(Reporter: nicksturm, Assigned: aaronlev)

References

(
URL
)

Details

(Keywords: access)

Attachments

(2 files, 2 obsolete files)

constrain new windows to be completely onscreen
1.77 KB, patch
aaronlev
: review+
jst
: superreview+
Details | Diff | Splinter Review
Self-explanatory demo case on screen.avail* properties
2.85 KB, text/html
Details 
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.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Apparently we don't observe SPI_GETWORKAREA unless we're maximized.

Should we be?
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Mozilla obscured by system bar → Mozilla not respecting SPID_GETWORKAREA when positioning new window
it's required by ms :)
URL: http://www.microsoft.com/winlogo/acce...
Funny, it doesn't appear that notepad respects that setting -- but I don't have
a copy of XP yet.
Summary: Mozilla not respecting SPID_GETWORKAREA when positioning new window → Mozilla not respecting SPI_GETWORKAREA when positioning new window
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.
Status: NEW → ASSIGNED
Keywords: access, sec508
Priority: -- → P1
Target Milestone: --- → mozilla1.3alpha
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?
Attachment #102682 - Flags: needs-work+
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.
Attachment #102682 - Attachment is obsolete: true
bug 130916 has a good argument for forcing windows completely on-screen. OSX
windows can be dragged only by their titlebar.
Blocks: 130916
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=
Attachment #103212 - Flags: superreview?(jst)
Attachment #103212 - Flags: review+
Comment on attachment 103212 [details] [diff] [review]
constrain new windows to be completely onscreen

sr=jst
Attachment #103212 - Flags: superreview?(jst) → superreview+
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
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
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?
Blocks: 181980
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: