Closed Bug 9454 Opened 26 years ago Closed 26 years ago

[dogfood][BETA]sched: XP & popup menus partially offscreen

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: mikepinkerton, Assigned: saari)

References

Details

(Whiteboard: [PDT-])

I need a routine that ensures that the windows created for tooltips appear totally on screen.
Severity: normal → minor
Status: NEW → ASSIGNED
Priority: P3 → P4
Target Milestone: M15
accepting bug, M15, P4.
Summary: Tooltips can appear partially offscreen → XUL Popups can appear partially offscreen
This will have to be solved for xul popups and, more importantly, xp menus. Renaming. This should probably go to hyatt, but i can hold onto it. adding him to cc list.
This bug is a dup of a bug I already have.
Depends on: 11304
we can only do this work after 11304 (rewrite of xul popups) happens.
*** Bug 11081 has been marked as a duplicate of this bug. ***
Depends on: 1877
adding 1877 as dep, as it was a dep of the dupe bug of hyatt's.
*** Bug 8550 has been marked as a duplicate of this bug. ***
Blocks: 12670
Summary: XUL Popups can appear partially offscreen → sched: XUL Popups can appear partially offscreen
Whiteboard: 1 day
this should probably be a sched task.
*** Bug 15436 has been marked as a duplicate of this bug. ***
*** Bug 15091 has been marked as a duplicate of this bug. ***
QA Contact: phillip → claudius
*** Bug 16067 has been marked as a duplicate of this bug. ***
Summary: sched: XUL Popups can appear partially offscreen → sched: XUL (popup) menus can appear partially offscreen
Severity: minor → normal
Priority: P4 → P2
Summary: sched: XUL (popup) menus can appear partially offscreen → sched: XP & popup menus can appear partially offscreen
Summary: sched: XP & popup menus can appear partially offscreen → [dogfood]sched: XP & popup menus can appear partially offscreen
Blocks: 11586
*** Bug 16155 has been marked as a duplicate of this bug. ***
Blocks: 16152
No longer blocks: 11586
Whiteboard: 1 day → [PDT+] 1 day
No longer blocks: 16152
Assignee: pinkerton → saari
Status: ASSIGNED → NEW
pushing xp menu bugs back to saari.
Target Milestone: M15 → M11
Target Milestone: M11 → M12
mass-moving most m11 bugs to m12
Assignee: saari → pinkerton
reassigning to pinkerton
Blocks: 18951
Status: NEW → ASSIGNED
Whiteboard: [PDT+] 1 day → [PDT+] 1 day 11/19
Assignee: pinkerton → saari
Status: ASSIGNED → NEW
going back to saari, he and pav started working on it while i was writing docs.
Whiteboard: [PDT+] 1 day 11/19 → [PDT+] 11/22 testing on linux
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+] 11/22 testing on linux → [PDT+]
Fixed it
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Implementation has problems on Windows (1999112313 build): 1. With extremely large root menus (such as a bookmarks menu with 100 items), or for any other root menu that has been moved up because it would run off the screen, moving the mouse over a submenu causes the root menu to move up & down, disappear and flash. This is the most serious of these three problems. 2. The bottom of long Mozilla menus are butted against the top of the Explorer taskbar. Instead they should float above the explorer taskbar and use the bottom of the screen as the menu absolute bottom limit. This is already done correctly by rods@netscape.com for his combo-box widgets. 3. Menu positioning for root menus (ie. View menu) that would run off the bottom of the screen is not as good as Windows does it. Currently Mozilla just moves the menu up enough so it does not run off screen. Unfortunately, this makes it cover the menubar. A better positioning algorithm for root menus in this case is to draw the menu completely _above_ the menu bar (bottom of the root menu should butt up against the top of the menu bar) if there is more screen space available above the menubar than below it. If there is not more screen space available above the menu bar than below it, then the menu bar should be drawn below the menu bar, but cropped and menu scrolling function takes over (related to another unfixed bug). This is already done correctly by rods@netscape.com for his combo-box widgets.
Whiteboard: [PDT+]
This code is implemented ontop of XP DOM APIs. Doing the perfect thing on each platform will be messy at best. I'll revisit this, but I'm removing the PDT+ so someone can decide if this is still a dogfood issue
I think the first bug in my list is definitely PDT+ (it makes menus with submenus worse than before this bug was "fixed"), and the 3rd one is marginal. 2nd one can wait, but it is probably a one or two liner fix. Are there really any big differences in how these menus should operate between platforms? I don't think Rod has had to make any special cases between platforms for his combo boxes, and they follow the Windows behavior well. The rule behind the Windows menu behavior is that a child menu should not overlap it's parent menu - simple as that. This allows you to fully see both parent and child menus on screen (you want to see what context the child menu has come from), and allows you to easily go back to selecting a parent menu item (when a child is open) by moving the cursor over it - something which is harder to do if they are overlapping.
I agee that the first should remain PDT+ but so should #3. The menu bar cannot be used when coverd by a drop down menu.
Blocks: 20203
Summary: [dogfood]sched: XP & popup menus can appear partially offscreen → [dogfood][BETA]sched: XP & popup menus can appear partially offscreen
Whiteboard: [PDT-]
Yes, bookmark problem should be fixed for Beta, but this is not mandatory for dogfood. Marking PDT-.
Priority: P2 → P3
Summary: [dogfood][BETA]sched: XP & popup menus can appear partially offscreen → [dogfood][BETA]sched: XP & popup menus partially offscreen
Target Milestone: M12 → M13
Having lists of problems is not acceptable in a bug report, this needs to be broken into multiple reports. Ideally, all three of Michaels listed problems would be separate bug reports, since the original problem has been resolved. To save time/work, let's consider this bug report to now refer to problem #1 only. targetting p3 for m13
Status: REOPENED → RESOLVED
Closed: 26 years ago26 years ago
Resolution: --- → FIXED
It might be better to move the three remaining issues with this implementation to new, clean bugs and close this one: 1. bug #21019 2. bug #21154 3. bug #21155
Status: RESOLVED → VERIFIED
marking verified as there are new bugs, thanks michael
Target Milestone: M13 → M12
No longer blocks: 18951
No longer blocks: 20203
You need to log in before you can comment on or make changes to this bug.