Title bar below Start bar



UI Design
19 years ago
10 years ago


(Reporter: Jens Bäckman, Assigned: jag (Peter Annema))


Windows 98

Firefox Tracking Flags

(Not tracked)



(1 attachment)



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

19 years ago
I'm fairly certain this is a duplicate.


19 years ago
Assignee: chofmann → don

Comment 2

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


19 years ago
Assignee: don → law
Target Milestone: M15

Comment 3

19 years ago
Bill, is this one for you or maybe danm?


19 years ago

Comment 4

18 years ago
Updating QA Contact.
Component: other → XPApps
QA Contact: leger → paulmac

Comment 5

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

Comment 6

18 years ago
spam, changing selected qa contact on selected bugs from paulmac@netscape.com to 
QA Contact: paulmac → claudius


18 years ago
Target Milestone: M16 → M20

Comment 7

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

Comment 8

18 years ago
nav triage team:

Not a beta1 stopper, marking nsbeta1-
Keywords: nsbeta1-

Comment 9

17 years ago
Marking nsbeta1- bugs as future to get off the radar.
Target Milestone: --- → Future

Comment 10

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

Comment 11

17 years ago
Created attachment 57915 [details] [diff] [review]
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

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

Comment 13

17 years ago
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.
Product: Core → Mozilla Application Suite
Assignee: law → jag
Priority: P3 → --
QA Contact: claudius
Target Milestone: Future → ---

Comment 14

10 years ago
We work exactly like Internet Explorer in all respects. 

So am going to call this bug WORKSFORME
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.