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.
I'm fairly certain this is a duplicate.
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.
Bill, is this one for you or maybe danm?
Updating QA Contact.
Component: other → XPApps
QA Contact: leger → paulmac
Move to M16 for now ...
Target Milestone: M15 → M16
spam, changing selected qa contact on selected bugs from firstname.lastname@example.org to email@example.com
QA Contact: paulmac → claudius
Move to M21 target milestone.
Target Milestone: M20 → M21
nav triage team: Not a beta1 stopper, marking nsbeta1-
Marking nsbeta1- bugs as future to get off the radar.
Target Milestone: --- → Future
This is certainly possible, although I have no idea how. Internet Explorer does it perfectly. Probably using some undocumented API.
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.
Just ignore me. I swear it worked on my home machine. Still looking.
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.
Assignee: law → jag
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: claudius
Target Milestone: Future → ---
We work exactly like Internet Explorer in all respects. So am going to call this bug WORKSFORME
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.