Closed
Bug 67913
Opened 23 years ago
Closed 22 years ago
New browser opens on top of "always on top" Smartcentre
Categories
(Core :: DOM: UI Events & Focus Handling, enhancement)
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: mrmazda, Assigned: mrmazda)
References
()
Details
Attachments
(7 files, 1 obsolete file)
13.76 KB,
application/octet-stream
|
Details | |
24.09 KB,
image/png
|
Details | |
3.66 KB,
patch
|
jhpedemonte
:
review+
jhpedemonte
:
superreview+
jud
:
approval+
|
Details | Diff | Splinter Review |
6.34 KB,
image/png
|
Details | |
18.53 KB,
image/png
|
Details | |
6.05 KB,
image/png
|
Details | |
654 bytes,
patch
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•23 years ago
|
||
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•23 years ago
|
||
It does that for me too (Warp 4.5, Build 2001020100)
Comment 4•23 years ago
|
||
This may be stupid question but what is the SmartCentre?
Assignee | ||
Comment 5•23 years ago
|
||
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•23 years ago
|
||
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.
Target Milestone: --- → Future
Assignee | ||
Comment 8•23 years ago
|
||
no improvement in 2001022800
Comment 9•23 years ago
|
||
Comment 10•23 years ago
|
||
Fix checked in. Should have a nightly to test in soon.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 12•23 years ago
|
||
Chatzilla opens on top of SmartCentre. 2001062912 OS/2
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 13•23 years ago
|
||
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•23 years ago
|
||
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.
Assignee | ||
Comment 15•23 years ago
|
||
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•23 years ago
|
||
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.
Assignee | ||
Comment 17•23 years ago
|
||
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?
Assignee | ||
Comment 18•22 years ago
|
||
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.
Assignee | ||
Comment 19•22 years ago
|
||
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•22 years ago
|
||
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.
Assignee | ||
Comment 21•22 years ago
|
||
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•22 years ago
|
||
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → WONTFIX
Assignee | ||
Comment 23•22 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 24•22 years ago
|
||
this is your bug charlie brown. however, the port owner isn't interested, his wontfix really means that.
Assignee: mkaply → mrmazda
Status: REOPENED → NEW
Comment 25•22 years ago
|
||
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?
Updated•22 years ago
|
QA Contact: madhur → rakeshmishra
Comment 26•22 years ago
|
||
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.
Assignee | ||
Comment 27•22 years ago
|
||
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.
Severity: normal → enhancement
Comment 28•22 years ago
|
||
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.
Updated•22 years ago
|
QA Contact: rakeshmishra → mkaply
Assignee | ||
Comment 29•22 years ago
|
||
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•22 years ago
|
||
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)
Assignee | ||
Comment 31•22 years ago
|
||
"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•22 years ago
|
||
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.
Assignee | ||
Comment 33•22 years ago
|
||
"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•22 years ago
|
||
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 :)
Assignee | ||
Comment 35•22 years ago
|
||
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•22 years ago
|
||
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"
Attachment #28839 -
Attachment is obsolete: true
Comment 37•22 years ago
|
||
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)
Attachment #90667 -
Flags: superreview+
Attachment #90667 -
Flags: review+
Comment 38•22 years ago
|
||
Fix checked in. I'm actually going to mark this fixed. We'll see what happens :) I'm asking for driver approval
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Keywords: mozilla1.0.1
Resolution: --- → FIXED
Updated•22 years ago
|
Attachment #90667 -
Flags: approval+
Comment 39•22 years ago
|
||
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+" keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1 → mozilla1.0.1+
Assignee | ||
Comment 41•22 years ago
|
||
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.
Assignee | ||
Comment 42•22 years ago
|
||
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•22 years ago
|
||
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)
Assignee | ||
Comment 44•22 years ago
|
||
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
Assignee | ||
Comment 45•22 years ago
|
||
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.
Assignee | ||
Comment 46•22 years ago
|
||
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•22 years ago
|
||
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
Assignee | ||
Comment 48•22 years ago
|
||
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•22 years ago
|
||
WarpSans is a taller font then Windows default Helvetica. If you'd like to open a separate bug on this, feel free.
Assignee | ||
Comment 50•22 years ago
|
||
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•22 years ago
|
||
Assignee | ||
Comment 52•22 years ago
|
||
This isn't truly fixed, as only the browser and mailnews fail to open on top of WarpCentre after a fresh migrate.
Comment 53•22 years ago
|
||
When those other windows are displayed, they aren't going through the normal window positioning code. No idea why.
Assignee | ||
Comment 54•22 years ago
|
||
Add to address book window opened with titlebar way above top of screen at 800 X 600 in release 1.1.
Updated•5 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•