Browser window partially hidden by Taskbar in Win95

RESOLVED FIXED

Status

SeaMonkey
General
P3
trivial
RESOLVED FIXED
19 years ago
10 months ago

People

(Reporter: jbeaupre, Assigned: Bill Law)

Tracking

({helpwanted})

Trunk
x86
Windows 95
helpwanted

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
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.

Comment 1

19 years ago
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.

Updated

19 years ago
Assignee: chofmann → german

Updated

19 years ago
Assignee: german → davidm

Comment 2

19 years ago
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.

Updated

18 years ago
Assignee: davidm → law

Comment 3

18 years ago
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.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M15
(Assignee)

Comment 4

18 years ago
> 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.
(Assignee)

Updated

18 years ago
Whiteboard: [HELP WANTED]

Comment 5

18 years ago
*** Bug 16547 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Component: other → Browser-General
QA Contact: leger → elig

Comment 6

18 years ago
Updating QA Contact.

Updated

18 years ago
Keywords: helpwanted

Updated

18 years ago
Whiteboard: [HELP WANTED]

Comment 7

18 years ago
Move to M16 for now ...
Target Milestone: M15 → M16

Comment 8

18 years ago
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.

Comment 9

18 years ago
*** Bug 36433 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Target Milestone: M16 → M20

Comment 10

18 years ago
Move to M21 target milestone.
Target Milestone: M20 → M21

Updated

17 years ago
QA Contact: elig → doronr

Comment 11

17 years ago
The same happens with Address manager windows (and perhaps other window types 
too?)
(Assignee)

Comment 12

16 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.