33188 - Nested submenus shouldn't overlap each other if possible

Status: RESOLVED WONTFIX

(Core :: XUL, defect, P3)

Description

[Matthew T (active 1999-2002)]

Build: 2000032308 trunk, MacOS 8.6

To reproduce:
* Open and maximize a Messenger three-pane window. Select a folder, if necessary,
  to bring up a message list.
* Move the mouse pointer over to the rightmost part of an item in the message
  list, and bring up the context menu.
* Select the `Move' menu item, to bring up the submenu for moving the message.
  Because there is not enough room for the context submenu to come up on the
  right of the context menu, it should come up on the left instead.
* Select an account from the submenu, to bring up the sub-submenu of folders for
  that account.

What should happen:
* The sub-submenu should appear on the left of the submenu.

What actually happens:
* The subsubmenu appears over the top of the original context menu, overlapping
  the original context menu.

The solution:
* In an ideal world, nested submenus wouldn't exist.
* But where they do, they shouldn't just appear `on the right, if there's room,
  otherwise on the left'.
* Instead, they should appear `on the same side of the parent menu as was used by
  the parent menu when appearing beside *its* parent, if there's room, otherwise
  on the other side'.
* So if you have nested submenus eight deep, currently they would be arranged
  horizontally on the screen like this
  1
   2
    3
     4
    5
     6
    7
     8
  but really, they should be arranged horizontally like this
  1
   2
    3
     4
    5
   6
  7
   8
  which would result in many fewer overlapping menus on average.

Ok?

Comment 1

[Mike Pinkerton (not reading bugmail)]

*** Bug 31838 has been marked as a duplicate of this bug. ***

Comment 2

[Mike Pinkerton (not reading bugmail)]

yup, all over this. i like your description ;)

Comment 3

[sairuh (rarely reading bugmail)]

yup. good suggestions, too. :-)

Comment 4

[Matthew T (active 1999-2002)]

Ah, stop it, you're making me blush.

Comment 5

[Ben Bucksch (:BenB)]

> * In an ideal world, nested submenus wouldn't exist.



What?





I'm seeing a more serious problem in bookmarks: I currently have a large top

level (doesn't fit on screen vertically), including a subfolder (appears approx.

at the middle of the screen), which contains a subfolder, which contains many

bookmarks again (too many to fit on screen). The last submenu content appears

over the top level content, although there's plenty of space on the left.



1

 2

3



1 = top level context (large)

2 = content of first subfolder (small)

3 = content of nested subfolder (large)



That's irritating at first, because you can distinguish 1 and 3 only by content,

not by form.



Raising severity to normal and resetting Milestone for reconsideration.

Comment 6

[Mike Pinkerton (not reading bugmail)]

you can touch the severity, but please don't touch the milestone. That is for my 
team's use only!

the reason it does this is because if the popup needs to be resized at all, it 
goes through the calculation to see which side of the parent has more room, even 
if that won't make any difference. I need to fix that, yes. Would you rather have 
this fixed at _the expense of features_? I didn't think so.

Comment 7

[Ben Bucksch (:BenB)]

> please don't touch the milestone.

OK, sorry.

> Would you rather have this fixed at _the expense of features_?

I did no priorization, but left it to you.

Comment 8

[Peter Trudelle]

Mass moving M18 bugs to M19

Comment 9

[John Morrison]

*** Bug 37695 has been marked as a duplicate of this bug. ***

Comment 10

[Peter Trudelle]

mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-

Comment 11

[sairuh (rarely reading bugmail)]

*spam*: transferring current XP Menu bugs over to jrgm, the new component owner.
feel free to add me to the cc list (unless am the Reporter) of any of these, if
you have any questions/etc.

Comment 12

[Mike Pinkerton (not reading bugmail)]

would like to fix for beta3

Comment 13

[timeless]

Would also like this fixed by rtm.

Comment 14

[Peter Trudelle]

rtm-, fix requires too large a change to consider for 6.0

Comment 15

[Ben Bucksch (:BenB)]

This is very irritating. Mozilla 1.0.

Comment 16

[amardare]

I added myself to the list.
This bug is worse than it seems:
Drag the main mozilla window near the bottom of your screen, so that only the 
menu bar is visible. The "Tasks" menu will pop up above the menubar, obviously, 
which is good.
Try now to open the "Tools" submenu ( Tasks->Tools ). The submenu is not even 
visible on the screen, because is positioned way,way outside the screen area.

Comment 17

[Mike Pinkerton (not reading bugmail)]

that is a different bug that ben has a fix for

Comment 18

[Ben Bucksch (:BenB)]

Some other solutions to related problems:
- The menus should have thicker 3D borders, appearing "higher" in the z-axis.
this wouild allow me to differentiate a submenu from a parent menu under it.
- The when a menu gets stacked on top of another one, make the top one 2 rows
(one on top and botton each) smaller, so I can access to perant menu by just
mousing over "looking-though" parent menu. Yes, that has the risk that I may
unintentionally close a whole bunch of menus, but we can use a delay and I don't
see a better solution.

Comment 19

[Ben Bucksch (:BenB)]

Bug 45700 is related.

Comment 20

[Mike Pinkerton (not reading bugmail)]

new owner

Comment 21

[Sylvestre Ledru [:Sylvestre]]

XUL + no activity for a while. Closing.