Closed Bug 13334 Opened 25 years ago Closed 25 years ago

[feature] Click on menu items disappears submenu

Categories

(Core :: XUL, defect, P2)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: cpratt, Assigned: mikepinkerton)

References

Details

(Keywords: platform-parity, regression, Whiteboard: 2 days TFD 4/14)

Build ID: 1999090808 Platform: RH Linux 6 (not seen in Win32 using 07-Sep-99 build) To reproduce: - Launch apprunner - Click on Bookmarks to drop down that menu. - Click on Search. - Click once on Search every few seconds. Result: You get into a rhythm in which every other mouse click will disappear the Search submenu. That is, the mouse clicks act as an on/off switch for the submenu. Expected result: The submenu should always be displayed. Subsequent clicks on the same submenu header should not visually do anything at all.
Assignee: trudelle → saari
reassigning to saari, cc pavlov
Status: NEW → ASSIGNED
Target Milestone: M11
Assignee: saari → pavlov
Status: ASSIGNED → NEW
Pav, I'm tossing this at you in the hopes that you can deal with it before I can :-)
mass-moving most m11 bugs to m12
I can't repro this on Win and I don't think I can on Linux either. The behaviour I get is that the menu totally disappears when I click the Search, and that is bug #15526, which you've seen. Probably related problems.
No, can't repro on Linux. I'm running Debian Potato. This is build 1999112208. I see bug #15526 behaviour instead, but not the click-thru part. When clicking thru on Linux, what's underneath is NOT clicked, but I do notice it doesn't get mouseover, but that's another bug.
Mass-moving non-PDT+ bugs to M13
Target Milestone: M13 → M14
I don't think is The correct behavior (like Motif 2.x and Windows, OS/2) should be: click item -> submenu appears click item again -> submenu disappears Unlike windows, it should work for secondary submenus too. This bug is related to #16876
The problem is you can either have popup on mouseover or toggle, but not both, or else you get a race condition where a mouseover followed by a click may or may not leave up the submenu. Under Windows for example, base menus have no mouseover but have a toggle, whereas submenus have mouseover but no toggle. Is suggest this is the best for the user, even if it is inconsistent.
Keywords: pp
Putting on beta1 radar.
Keywords: beta1
If I click on the 'Search' menu item with mouse, the whole 'Bookmarks' menu is dismissed. I do not see the submenu going on/off. Used M13(2000012520) and M14(2000012609) builds on Linux.
this is not limited to linux --i see this on all three platforms. updated summary/platform info. tested with the following M13 comm bits: mac 2000-01-26-03 linux 2000-01-25-20 win 2000-01-25-20
OS: Linux → All
Hardware: PC → All
Summary: [PP] Linux - Click on menu items disappears submenu → [4.xP] Click on menu items disappears submenu
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
If you're going to make this xp, you'll want to dupe bug #15526 as this previously covered this on windows (except the click passes through the menus when they dismiss). I'm not sure this as it stood in the original report was a dupe of that, but the latest descriptions are of bug #15526 behaviour.
Setting the keyword all open [4.xp] bugs to 4xp.
Keywords: 4xp
pink *loves* menu bugs
Assignee: pavlov → pinkerton
this the the behavior i see: macOS: clicking the parent closes the entire menu (parent + hierarchical). winNT: clicking the parent does nothing no matter how many times you click. linux (gtk): selects the first item of the submenu. submenu remains open no matter how many times you click. So regardless, the popup should not toggle as no platform i see does that. cc'ing trudelle.
This bug was erroneously tagged beta1, removing that and the PDT+ designation, and moving to m15 Since these are XP menus, we may leave some PP, and therefore some 4xp, differences unresolved. In such cases, we should probably default to Windows-like behavior, since it is the largest userbase, and since even Mac menus are gravitating towards Windows behavior over time.
Keywords: beta1
Whiteboard: [PDT+]
Target Milestone: M14 → M15
My build 2000020214 still dismisses submenus on GTK.
bulk accept
Status: NEW → ASSIGNED
Summary: [4.xP] Click on menu items disappears submenu → Click on menu items disappears submenu
hyatt and i looked at this one tonight and it's pretty hairy. Essentially, the menu rollup listener impl for each platform only knows about the current widget. Any clicks outside that widget will cause the entire chain to disappear and the system to be reset to nothing active. This is also the cause of why when you click in the menu header of a menu that is visible (in the menubar), it will deselect and the rollover feedback on the menu header will go away. What we need to do here is have a stack of widgets that the rollup listener can check against (not just a single, current, widget) to see if the click is outside of all of them. This is so M15, at least.
*** Bug 15526 has been marked as a duplicate of this bug. ***
*** Bug 26757 has been marked as a duplicate of this bug. ***
*** Bug 28041 has been marked as a duplicate of this bug. ***
*** Bug 29297 has been marked as a duplicate of this bug. ***
*** Bug 29402 has been marked as a duplicate of this bug. ***
Priority: P3 → P2
Summary: Click on menu items disappears submenu → [feature] Click on menu items disappears submenu
Whiteboard: 2 days
Both mac and windows behavior make sense. I'd like automatic menu mouse tracking without mouse press to be optional, because it is very annoying sometimes... When it is on, windows behavior makes most sense. (no dismiss of any menus on click). When it is off, mac behavior makes sense. Click to activate submenu, click to dismiss it. The toggling behavior was also present on Motif 2.x In any case, dismissing the menu and any parent menus is not desired.
The important thing to me is not whether the second click on the same menu item toggles visibility of that submenu (though I'd rather it didn't), but that a click on a different item bring up its submenu (right away, no delay) rather than making the whole menu hierarchy disappear. Then I can tune the submenu delay long (well, if Pav lets me make it prefable -- right now it's hardwired in nsLookAndFeel.cpp) to get Motif-style behavior.
It is designed to do that already. This bug is just making the whole menu close up early so that you never see that. :)
*** Bug 32075 has been marked as a duplicate of this bug. ***
*** Bug 33721 has been marked as a duplicate of this bug. ***
Adding myself to CC list
akkana: I agree :) (delay=3600sec :) (It would be nice if the click toggles though).
The personal submenu delay tuning is in ... add a line like user_pref("ui.submenuDelay", 3600000); to your prefs.js or user.js. So once this bug is fixed, everything should work.
*** Bug 29867 has been marked as a duplicate of this bug. ***
back to m16, won't get to this by m15.
Target Milestone: M15 → M16
*** Bug 35182 has been marked as a duplicate of this bug. ***
Whiteboard: 2 days → 2 days TFD 4/14
*** Bug 35460 has been marked as a duplicate of this bug. ***
*** Bug 29867 has been marked as a duplicate of this bug. ***
fixed.
What builds will this start appearing in? I still notice the problem in build 2000041406 for Win32
really marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Reopening. This worked on yesterday's 20000416xx build(s), but the same problem is back with 2000041705: click on submenu item dismisses the entire parent menu. regression.
Status: RESOLVED → REOPENED
Keywords: regression
Resolution: FIXED → ---
hmm. nevermind, that was odd....when I downloaded the nightly build, all the changes from the previous (couple of?) builds had been gone, though the Build ID denoted that it was, in fact, the latest nightly. In reality, it really seemed to be from like a week ago. Very strange...good thing I didnt go around and reopen like 20 bugs :) Marking fixed...
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Interesting -- I saw the same thing with a 4/14 build a friend downloaded off mozilla.org (it had the right timestamp but lacked several fixes that should have been in 4/14).
sounds like the wrong build got posted or somethin...
The reason is some of the nightly builds are M15 builds and some of the nightly builds are M16 builds as a feature freeze is on for M15 all new feature work goes into the M16 tree. However it's impossible to see from the /pub/mozilla/nightly/latest/ directory whether you've got a M15 or a M16 build (unless you're using a Mac build where the milestone is contained in the filename). You can see if you've got a M15 or an M16 build by going to http://ftp.mozilla.org/pub/nightly/latest/ and see if your build ID has an M15 or and M16 after it (perhaps this information should be added after the build ID displayed on Mozilla?). It's likely the M15 builds won't have this fix but the M16 ones will.
Hmm remove the latest part from that URL to see the individual directories where the nightly builds are, it should have read: You can see if you've got a M15 or an M16 build by going to http://ftp.mozilla.org/pub/nightly/ and see if your build ID has an M15 or and M16 after it....
Status: RESOLVED → VERIFIED
verif fixed on winNT and linux, using opt comm bits 2000.04.21.09 (m16). not really an issue on mac (since the main menu is native and behaved that way in 4.x anyhow).
You need to log in before you can comment on or make changes to this bug.