Menus end at the screen boundaries, however the task bar isn't recognized, so the last item(s) disappear behind it. Proposed fix: alter the code, that determines and reports the boundaries of the screen, from reporting the real monitor boundaries to reporting the boundaries of the currently visible (to honor multiple monitors or vitual desktops) and for applications available space.
Summary: "Screen" excludes Taskbar → [Win32] "Screen" excludes Taskbar
Assignee: trudelle → saari
Priority: P3 → P4
Target Milestone: M14
reassigning to saari as p4 for m14, cc hyatt
Dan, does changing what the DOM screen reports as its size sound like the right way to go about this? Does the DOM spec even address this?
You don't really want to mess with the basic screen size, since some parts of the code (JS, for instance) need to know both. See the distinction between screen.width and screen.availWidth: one is actual size, the other is useable, client size (minus things like system toolbars and the Mac menubar). Sounds like you just need the "avail" numbers. These are things theoretically already tracked by the DOM screen object and by gfx device contexts, if you can get to one of them from wherever you are.
Summary: [Win32] "Screen" excludes Taskbar → [Win32] Menu items disappear behind taskbar
Good. Withdrawing proposed fix :-) and changing summary from "[Win32] "Screen" excludes Taskbar" to "[Win32] Menu items disappear behind taskbar".
GetAvailWidth and GetAvailHeight *are* what is being called. Next theory please. Oh yeah, I'm giving this to Dagley. Steve, nsMenuPopupFrame::SyncViewWithFrame is the place where all this positioning happens.
Passing the menu bug torch to pinkerton
Assignee: sdagley → pinkerton
*** This bug has been marked as a duplicate of 21154 ***
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
Verified dupe of 21154
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.