20965 - Title bar below Start bar

Status: RESOLVED WORKSFORME

(SeaMonkey :: UI Design, defect)

Description

[Jens Bäckman]

This is a very silly bug that many Windows apps still has. It is very
easy to duplicate:

1) Move the Start bar to the top of the screen
2) Start Mozilla
3) Get annoyed, because the title bar ends up below the start bar

This is a very petite bug that needs very little attention, although it
is pretty annoying.

Comment 1

[Eli Goldberg]

I'm fairly certain this is a duplicate.

Comment 2

[Sean Richardson]

It is very doubtful that anything can be done about this.
The Win9x/NT4 Taskbar is dockable to any edge of the screen, but once there,
it is effectively not part of the desktop area for Win32 apps. This can
be clearly seen by maximizing a Win16 app (Word for Windows 6, etc) and a Win32
app (any) on a Win9x desktop: the Win16 app obscures the Taskbar, because it
doesn't know that that area isn't part of the desktop, while Win32 apps do know
that, and maximize only to the inner edge of the Taskbar, which is always
outside (docked against a screen edge). That's half of it.

The other half: all jokes about Win95 = Mac '86 aside, in MS-Windows the
application title bar and menu bar have always been integral to the
application window, unlike on the Mac.

Putting the application title bar above the system taskbar at the top of
the window may not be possible at all, and if it were possible, would
require treating the title bar as an associated but independent window.

Personally, seeing the system taskbar between the application title bar
and the application menu bar would drive me batty, but I don't expect to
ever see it. (Tested with Explorer on WinNT 4 and WIN98 SE)

If no Win32 app could ever put the title bar above (short of hacking
undocumented system interfaces) Mozilla couldn't be expected to.

I have no idea what the situation is with Win 2000.

Comment 3

[don]

Bill, is this one for you or maybe danm?

Comment 4

[leger]

Updating QA Contact.

Comment 5

[don]

Move to M16 for now ...

Comment 6

[Paul MacQuiddy]

spam, changing selected qa contact on selected bugs from [e-mail] to 
[e-mail]

Comment 7

[don]

Move to M21 target milestone.

Comment 8

[Paul Chen]

nav triage team:

Not a beta1 stopper, marking nsbeta1-

Comment 9

[Paul Chen]

Marking nsbeta1- bugs as future to get off the radar.

Comment 10

[Mike Kaply [:mkaply]]

This is certainly possible, although I have no idea how. Internet Explorer does 
it perfectly. Probably using some undocumented API.

Comment 11

[Mike Kaply [:mkaply]]

Attachment: Fix for problem - use AvailRect not Rect

The bug was that in nsDeviceContextWin.cpp, Rect was being used on the screen
rather than AvailRect for ComputeClientRectUsingScreen

This needs to be tested with fullscreen mode, but it fixes it for me.

Comment 12

[Mike Kaply [:mkaply]]

Just ignore me. I swear it worked on my home machine. Still looking.

Comment 13

[Bill Law]

Whenever I've looked into this I've concluded that we're doing about as well as
can be expected.  We respect the start bar whenever it has properties that cause
it to always appear (e.g., always on top and auto-hide off).

Unless the start bar has those properties, I don't think we should pay any
attention to it (because our window will be on top of it if always-on-top is
off, or visible if it is hiding).

Mike, the subtleties of these properties might be what had you thinking your
code was working on one system but not another.

Comment 14

[Mike Kaply [:mkaply]]

We work exactly like Internet Explorer in all respects. 

So am going to call this bug WORKSFORME