Mozilla (8.5) assumes the Taskbar is at the bottom of the screen. While the Taskbar is at the top (feels more comfortable after using a Mac), Mozilla places itself at the upper left part of the screen and becomes partially obscured by the Taskbar (maximize and minimize buttons are hidden, plus the top of the menus). This is a common, but not universal, problem with a lot of software. The workaround is to move the Taskbar and move it back.
Using build 081299 on Windows 98 SE (4.10.2222 A) the same problem is present. Communicator 4.61 and Navigator 3.04 Gold do not have this problem.
The bug is actually window related in that the default apprunner window size should take into account the win9x taskbar height for calculating available screen space. This should only be relevant for case when seamonkey windows are maximized, or when opening the window at the first time. (forwarding to davidm to verify this is working, david feel free to close if it is) The task bar UI design itself (positioning) follows the spec for the ui framework. The task bar will beat the bottom since it has nothing to do with the other toolbars which are app-specific. This is to support logical grouping of related functionality. Part of the larger UI design framework is that the taskbar will be on the bottom every major window of the app in order to offer seamless and universal access to apps functionlity whether local or on the net. The problem with the coverup of the bottom area is a) not specific to the task bar being down there (the same case could otherwise be made for the status bar) and b) and overlap should only occur for a smaller percentage of users who have customized the win9x taskbar to slide out on mouseover which is how all other win32 windows will behave.
I am reassiging to law since I don't know how the windows code works. Note that GFX has a routine to return the visible area of the window excluding the taskbar and should give the top and left left pixels to be used.
> since I don't know how the windows code works Oh, like I know how the windows code works :-). It works pretty damn well, if you're Bill Gates. I'm putting this on the back burner.
*** Bug 16547 has been marked as a duplicate of this bug. ***
Updating QA Contact.
Move to M16 for now ...
This "creeping under the taskbar" bug happens to a lot of applications under Win32, and is caused by using the wrong Win32 API functions to retrieve and set window positions. I haven't checked the Mozilla source about this, but I'm certain that: - When the window position(s) need to be saved, their coordinates are retrieved using the GetWindowPlacement() API function. - When they need to be restored, the window position is being set using the SetWindowPos() API function. This causes the described problems, because GetWindowPlacement() uses coordinates relative to the taskbar, and SetWindowPos() uses coordinates relative to the top left of the screen (and does NOT care where the taskbar is). If the taskbar is at the bottom of the screen, the absolute and relative origins coincide, so nobody notices any problem, but if the taskbar is put at the top, then the origins differ by exactly 1 taskbar's height, causing the window to "creep" up every save/restore cycle. The solution to this problem is to use the SetWindowPlacement() function when a window position needs to be set. This function can also automatically restore minimed/maximized/normal states, in one call. I'm gonna lookup some article about this stuff on the M$ KB site, but at the moment it's slow as a snail, so I'll post it later.
*** Bug 36433 has been marked as a duplicate of this bug. ***
Move to M21 target milestone.
The same happens with Address manager windows (and perhaps other window types too?)
Resolving FIXED. We appear to handle this "properly" (as best as can be determined; it does seem to work just like IE). We will not overlay the task bar if the task bar properties for "always on top" is set and "auto hide" is not set. Verified for Address Book window, also.