67913 - New browser opens on top of "always on top" Smartcentre

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, enhancement)

Description

[Felix Miata]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; m18) Gecko/20010201
BuildID:    2001020 100

With browser maximized and Smartcentre set to be always visible at top of
screen, clicking form button that opens new window causes new window to fully
obscure Smartcentre.

Reproducible: Always
Steps to Reproduce:
With browser maximized and Smartcentre set full time to top of screen, click
form button that opens new window.

Actual Results:  Smartcentre hidden.

Expected Results:  Apps should not obscure Smartcentre.

Comment 1

[Felix Miata]

Problem not limited to second browser instance open. Also applies to second
instance of messenger, manage bookmarks, create email message, and at least one
other I can't remember. OS/2 Warp 14.062d

Comment 2

[Michael Hendy]

It does that for me too (Warp 4.5, Build 2001020100)

Comment 3

[Keyser Sose]

Marking NEW as per comments.

Comment 4

[joki (gone)]

This may be stupid question but what is the SmartCentre?

Comment 5

[Felix Miata]

SmartCentre is the original Lotus name for what Warp users call WarpCentre. 
AFAIK, on windoze systems it is still called SmartCentre if it is installed 
with Smartsuite. Sorry for brain lapse when originally titling.

Comment 6

[joki (gone)]

Okay.  I don't have a Warp machine to play with at the moment though it sounds 
like an issue in the Warp widget implementation.  Not sure who would own that.  
Setting milestone.

Comment 7

[Mike Kaply [:mkaply]]

joki, I'll take this one - it's Os/2 only

Comment 8

[Felix Miata]

no improvement in 2001022800

Comment 9

[Mike Kaply [:mkaply]]

Attachment: Accomodate position of smartcenter is setting of AvailRect

Comment 10

[Mike Kaply [:mkaply]]

Fix checked in.

Should have a nightly to test in soon.

Comment 11

[Madhur Bhatia]

QA contact updated

Comment 12

[Felix Miata]

Chatzilla opens on top of SmartCentre.
2001062912 OS/2

Comment 13

[Felix Miata]

Prefs dialog, mail window, chat window, address book, & composer open on top of 
WarpCenter in OS/2 3 Aug build 0000000000. Each closed so that only browser is 
open when selecting the new task. Freshly migrated profile after eliminating 
all traces of previous Mozilla build and "installing" fresh. "Installing" 
consisted of deleting all files in and under \Mozilla\bin except mozilla.exe 
and mozilla.ico (so as not to disturb desktop objects during reinstall) as well 
as all previous Mozilla profiles before unzipping the build archive.

Comment 14

[Mike Kaply [:mkaply]]

Where do you get the belief that nothing should ever open on top of the 
WarpCenter?

I agree that nothing should maximize over it, but I know of no requirement that 
nothing ever open over it.

Comment 15

[Felix Miata]

Settings notebook includes option: "show on top of maximized windows". To me 
this means WarpCentre is supposed to preempt everthing else, forcing everything 
else to use that portion of CRT screen above/below WarpCentre. Any app 
attempting to steal WarpCentre's reserved space is misbehaving (belligerent). 
Maybe such behavior is by design of the WPS, but it stinks, regardless of why. 
If it is the fault of WPS, Mozilla should still be made to honor the setting, 
thus making it friendlier, improving usability. Call it RFE if you must.

Comment 16

[Mike Kaply [:mkaply]]

As the preference says, this only applies to maximied windows.

What this WPS setting does is cause windows when maximized to not go over the 
WarpCenter.

It says nothing about non maximized windows which is what we are talking about.

When we open Mozilla windows for the first time, most of them use the operating 
system flag FCF_SHELLPOSITION which lets the operating system determine the 
initial position. I wrote a testcase that created 20 windows using 
FCF_SHELLPOSITION and they do overlay the WarpCenter in some cases.

So this would be an operating system enhancement to cause windows to never 
overlay the warpcenter.

Comment 17

[Felix Miata]

With browser I just did "open in new window" 3 times, then reopened address 
book, then prefs. None opened on top of WarpCentre. I guess first time open 
imposition on WarpCentre is de minimus. How about a switch to RFE on this?

Comment 18

[Felix Miata]

2002021216 seems to be OK except after a fresh migrate or new profile, when
everything that gets opened for the first time starts at 0,x. After that,
positions are remembered, and subsequent instances are no longer shifted upward
to obscure WarpCentre if the remembered position does not obscure WarpCentre.

Comment 19

[Felix Miata]

2002031516

F11 (full screen) causes WarpCentre to disappear. This should not be permitted 
when WarpCentre is set to "always on top". Always means always.

Comment 20

[Mike Kaply [:mkaply]]

Um, no. Full screen means full screen.

You can't have it both ways.

This is working the same on OS/2 as it does on windows. On windows when you go 
fullscreen (with IE or Mozilla) the start bar is gone.

Comment 21

[Felix Miata]

Always means always, not almost always. OS should preempt apps. Whatever size
the OS says full screen is is all an app should get. With WarpCentre set to
always that should mean about 25 pixels or so less than screen height.

How it works in windoze is irrelevant in OS/2. Nothing really works in windoze.
Anything that appears to work in windoze is either an illusion or temporary or both.

Comment 22

[Mike Kaply [:mkaply]]

Sorry but fullscreen means fullscreen and that's the way it is going to be. Full 
screen is designed to take over the entire screen, period. On all platforms.

Comment 23

[Felix Miata]

When I open Konqueror 2.1 in Caldera Linux 3.1 and KDE, and click the maximize
button near the upper right corner, the taskbar at bottom of screen remains
visible (in prefs automatic hide not enabled; enable hide button enabled).

When I open Netscape Communicator 4.77 in Caldera Linux 3.1 and KDE, and click
the maximize button near the upper right corner, the taskbar at bottom of screen
remains visible (in prefs automatic hide not enabled; enable hide button enabled).

When I open Netscape Communicator 4.79 in windoze 98, and click the maximize
button near the upper right corner, the taskbar at remains visible (in taskbar
properties always on top checked; auto hide unchecked).

When I open IE 4.72.3110 in windoze 98, and click the maximize button near the
upper right corner, the taskbar at remains visible (in taskbar properties always
on top checked; auto hide unchecked).

I would check Mozilla on Mandrake 8.1 too, expecting the same result as the
above four, but would need to reboot this system to do it, as the IBM IDE HD
running Mandrake in another box died at age 3 months and has not yet had Linux
reinstalled since replacement.

OS/2 appears to be the only OS that allows an app to usurp the space devoted to
the OS's control center.

Comment 24

[timeless]

this is your bug charlie brown.

however, the port owner isn't interested, his wontfix really means that.

Comment 25

[Mike Kaply [:mkaply]]

Maximize and fullscreen are two completely different things.

You can't compare them. When you maximize the browser it doesn't cover the smart 
center.

What exactly are you talking about?

Comment 26

[Mike Kaply [:mkaply]]

Felix,

Do we have resolution on this?

Fullscreen covers the WarpCenter, maximize does not.

Please let me know. I'd like to get this off the books.

Comment 27

[Felix Miata]

NAICT, the WarpCentre design is the real problem, so the ideal fix would have to
come from an IBM fix to the OS, to make WC prefs provide an option to treat
windowed and fullscreen and maximized equally as not allowing intrusion upon WC
screen space, as if the space did not even exist.

I'm in no position to attempt to persuade IBM to make such a change, and made no
apparent headway in trying to get Serenity to do it either.

Since fullscreen seems to be universally intended to literally preempt
everything, maybe nothing can or should be done to change that. However,
regardless that the OS permits a user to cover WC with a windowed app, I think
apps should play nice by never attempting to use the system toolbar space.

In windoze, the taskbar has a setting "always on top". KDE for Linux provides
for the same behavior. OS/2's WC has instead "show on top of maximized windows",
which permits the unfriendly space intrusion. I think Mozilla for OS/2 could and
should someday be programmed to treat "show on top of maximized windows" as if
it were the windoze taskbar set to "always on top", making the overall behavior
similar cross-platform.

Changing to RFE.

Comment 28

[Mike Kaply [:mkaply]]

Attachment: warpctop.zip

When you click on this attachment, save it as WARPCTOP.ZIP

Unzip it.

If you run WARPCTOP.EXE everytime your system boots, WarpCenter will be marked
as topmost and no application will be able to cover it.

Comment 29

[Felix Miata]

Attachment: screenshot after F11

Latest available trunk build, 2002070308

First thing I tried you see. This is not the behavior I hoped for, but maybe
that is a PM limitation? I expected the available rectangle and the apparent
screen size to be the same in excluding the height of WarpCentre from the
total. The same problem happens with a window dragged up over WC. It leaves the
title bar and therefore mouse access to resize, move, close, etc inaccessible
as a layer underneath WC.

Does this utility have an unload switch? Can it be killed?

Comment 30

[Mike Kaply [:mkaply]]

If you close and reopen the smartcenter, it will go back to the way it was. 
(right click context menu and close)

You asked that the smartcenter always be on top and that's what I was showing 
you.

You can't have it both ways. You can't have screen real estate that behaves as 
if it isn't there.

I'm not sure what to tell you.

There really isn't a way to accomplish what you want. You can have it always on 
top and set the "Show on top of maximized windows" flag in WarpCenter and it 
will behave mostly like you want, but yes if you put a window behind it, it will 
be behind. That's what you asked for (windows can't go over smart center)

What exactly would you expect a window to do when it is moved over the 
smartcenter (easier to see if smartcenter is at the bottom of the desktop)

Comment 31

[Felix Miata]

"You can't have screen real estate that behaves as if it isn't there."

Why not, at least in future if not currently?

Your second question is covered generally below.

Not having a working familiarity with windoze, it takes some work for me to
compare its toolbar to WarpCentre. At this writing I have a Pentium 66 with
W95OSR2  and Netscape 4 to compare with. Both allow the toolbar to be configured
with top of screen placement and thus to obsure a window's titlebar and its
critical grab handle, menu, and buttons, not all of which in windoze have a
keyboard equivalent that can be used to recover from, e.g. no Alt-F7 move hotkey
as in OS/2. When placed at bottom of screen, obstruction of browser frame icons
is a lesser problem, but still a problem.

What bothers me in both is that neither are capable of shutting off from other
apps the screen real estate they occupy, at least to the extent that the
titlebar can ever be obstructed. I can understand allowing any window to be
dragged partially offscreen to left, right, and bottom, but I can't understand
why the designers of either OS allow in any manner a window's titlebar to be
pushed offscreen vertically. In a GUI, the titlebar is too crucial a tool to be
inaccessible. Thus it follows that when a critical toolbar is positioned at
screen's edge *and* set to preempt the space as to apps, that it is nevertheless
possible for the toolbar to obstruct a titlebar that in effect should be the
edge of the screen that a titlebar should not be permitted to pass is a major
desktop design flaw.

It is my contention that the space the toolbars occupy should be treated by all
apps as non-existent space, that toolbar borders adjacent to desktop space
should be treated as the edge of the screen, whenever the toolbar setting is
equivalent to always visible or always on top, and that if such a setting is
missing (WC) that is yet another desktop design flaw.

At least some portion of a window's titlebar color should *always* be above the
desktop space when not minimized.

All that is not the fault of Mozilla. It would be nice if Mozilla were coded to
behave as if these desktop design flaws in both operating systems didn't exist,
i.e. - Mozilla simply not allow the edge of its own titlebar to cross the border
between desktop and "always on top" toolbar placed at the top of the screen. It
would be nicer still if IBM would remove the flaws from PM that allow any app's
titlebar to make such intrusion, and probably for M$ to do the same if they
haven't already in their latest version.

AFAI'C, showing the toolbars only on mouseover is an even bigger problem I don't
want to get into. I want full time mouse access to shutdown and certain of the
other tools they contain.

Comment 32

[Mike Kaply [:mkaply]]

I can always move a window so that the titlebar is offscreen.

Even if the WarpCenter was treated as if it wasn't there, you could still end up
with a titlebar behind it. 

I don't understand what you expect to happen if you move a window such that its
titlebar is where the warpcenter is.

Do you expect that a Window simply can't ever be moved offscreen?

That would be horrible.

Comment 33

[Felix Miata]

"I can always move a window so that the titlebar is offscreen."

I consider any ability to move the titlebar beyond the top edge of the screen to
be a desktop design flaw.

"Even if the WarpCenter was treated as if it wasn't there, you could still end up
with a titlebar behind it."

This I am having a problem visualizing.

"I don't understand what you expect to happen if you move a window such that its
titlebar is where the warpcenter is."

I consider the possibility that it is possible to do such a thing when the tool
is at the top of the screen and set to preempt a desktop design flaw.

"Do you expect that a Window simply can't ever be moved offscreen? That would be
horrible."

Yes, as to the top; No, as to the sides and bottom; that is, until and unless it
becomes possible to put titlebars at other than the tops of the windows.

Comment 34

[Mike Kaply [:mkaply]]

Well now you have totally gone beyond the realms of anything Mozilla could do.
You are asking for a redesign of the OS/2 window manager to behave more like
Windows.

So what exactly is this bug about now in relation to Mozilla? We can't fix these
problems in the browser.

The only solution to your problem is to use Windows which behaves exactly like
you want :)

Comment 35

[Felix Miata]

I right clicked WarpCentre and clicked "close". That exited WC. Then I went to
the system folder and reopened it. When I next opened Mozilla bookmarks, they
still scrolled underneath WC. Had to reboot to regain access to the bookmarks
scroller.

That one thing about windoze is the only thing I'm aware of that works better
than OS/2, except that even that thing does not work better in windoze, which
allows an accidental excursion of the titlebar off the top with no way to
recover it.

It still seems like any app ought to be able to find the line between the
top-placed toolbar and the desktop, treat it like the top edge of the screen,
and refuse to cross it.

Comment 36

[Mike Kaply [:mkaply]]

Attachment: Fix

OK, I get it. I really do.

The issue was that I thought ConstrainPosition in nsWindow was doing the right
thing, but it wasn't.

I have modified the OS/2 ConstrainPosition to never allow Mozilla to position
windows on the warpcenter when it is at the top of the screen. When it is at
the bottom, we offset by the warpcenter height.

I have also changed the "slop" value. This value indicates how much of a window
is required to stay on screen when mozilla positions it. For instance if you
close Mozilla with only the border showing to the left, right or bottom, when
you start it again, at least "slop" pixels will now be displayed (I made this
100 pixels)

We also honor the "show on top of maximized windows"

If you have this set, we will display over the WarpCenter, which is expected.

Note this change ONLY affects windows that Mozilla displays and positions,
including the initial window.

Preventing a user from moving a Window offscreen is beyond the scope of this
bug, and would interfere with things like multiple desktop applications.

So I consider this the "fix"

Comment 37

[jhp (no longer active)]

Comment on attachment 90667 [details] [diff] [review]
Fix

You should initialize lWorkAreaHeight in case "if ( pfnQueryDesktopWorkArea &&
!rc )" fails.  Otherwise, r=pedemonte
sr=blizzard (platform specific code)

Comment 38

[Mike Kaply [:mkaply]]

Fix checked in.

I'm actually going to mark this fixed.

We'll see what happens :)

I'm asking for driver approval

Comment 39

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 40

[Mike Kaply [:mkaply]]

Fixed on branch

Comment 41

[Felix Miata]

2002071108 OS/2 trunk

Without a fresh migrate, I'm not sure how well this fix can be tested.

This is not actually fixed. The summary never got changed to reflect additional
comment #1.

I opened a whole bunch of browser windows. The first opened a few pixels lower
than the original, which is fine. Puzzling is that each additional browser
window, no matter how many, opens at the height of the second. The position
shift is only horizontal, all of which is not a problem, just a little
unpolished maybe.

I opened Chatzilla (1st since migrate), and it opened at 0,0, obscuring the
toolbar. I don't know whether to resummarize and/or reopen, open a new bug, or
leave it alone and let you adjust the current fix.

Comment 42

[Felix Miata]

Attachment: Screenshot 800 X 600

When Mozilla opens a window that was last opened butted up against WarpCentre,
it always positions it about 25% of the WC height below WC instead of in the
remembered position. Since I keep my browser "window" height maximized, first
open causes the bottom to go off screen in creating this unwanted gap.
Apparently this is the same behavior as my long paragraph in comment #41.

Comment 43

[Mike Kaply [:mkaply]]

Interesting. The bug about being too far shifted below WarpCenter only happens 
at 800x600 and appears to be a bug in the OS/2 API WinQueryDesktopWorkArea.

Easy to workaround though - already have a fix.

IRC is going to be a little harder. It appears to be an XP bug. The chatzilla 
window doesn't go through the constrainposition code.

And as far as new windows (mail and newsgroups, etc.) opening at the same place 
vertically, again XP.

If you open multiple browser windows they cascade.

So I believe the only OS/2 issue left here is the WarpCenter positioning bug and 
I will check in a fix for that (won't make today's build though, sorry - cutoff 
is in 1 minute)

Comment 44

[Felix Miata]

Attachment: screenshot - adding to address book

If I use Alt-F7 to move it, complete it, and exit, when I do it again the next
time it still opens past the top of screen. 2002071208 OS/2 trunk

Comment 45

[Felix Miata]

Still at 800 X 600. I just realized that the new card panel height is taller
than the space remaining after subtracting WC height from 600 px.

Comment 46

[Felix Miata]

Attachment: screenshot - a gap?

My eyes aren't as good as they uztabe. Looks like enough space between titlebar
and bottom of WC to squeeze in the mousepointer and get focus on desktop
instead of WC or Moz. Eye tricks? Or a real gap? I can push it higher, but Moz
won't.

Comment 47

[Mike Kaply [:mkaply]]

Nope, no gap. It's the 3D effect of the window.

And there is nothing I can do about dialogs that are bigger than the screen.

Mozilla wasn't designed to be run at 800x600

Comment 48

[Felix Miata]

The W2K toolbar is about 25% taller than WC. New card in W2K 2002061808 at 800 X
600 is short enough to fit between edge of toolbar and edge of screen with space
to spare below and above, and opens overhanging the bottom of screen instead of
with titlebar off top of screen. W2K's new card is roughly as much shorter than
the available space as OS/2's card is taller.

New card has way more vertical whitespace than it needs, but that isn't a
platform specific problem.

Comment 49

[Mike Kaply [:mkaply]]

WarpSans is a taller font then Windows default Helvetica.

If you'd like to open a separate bug on this, feel free.

Comment 50

[Felix Miata]

I wish you wouldn't couch your new bug suggestions quite the way you do. You
usually get me filing before querying. This time I remembered first. Bug 63941
covers the new card size.

Still, the excess height should cause the bottom to be off screen, not the top.

Comment 51

[Mike Kaply [:mkaply]]

Attachment: For reference, the additional patch that was applied

Comment 52

[Felix Miata]

This isn't truly fixed, as only the browser and mailnews fail to open on top of
WarpCentre after a fresh migrate.

Comment 53

[Mike Kaply [:mkaply]]

When those other windows are displayed, they aren't going through the normal
window positioning code. No idea why.

Comment 54

[Felix Miata]

Add to address book window opened with titlebar way above top of screen at 800 X
600 in release 1.1.