Closed Bug 140767 Opened 22 years ago Closed 22 years ago
unnormal behavior when leaving menu (menus don't open when hovered while another menu is open)
When a menu item like "Bookmarks" is open and I point to "Tools" it is ignored. I have to click onto "Tools" to see what's in the menu. In earlier versions (e.g. 1.0rc1) the menu "Tools" is shown directly after entering the next entry with the mouse pointer (without a mouse click).
The used mozilla build was: 2002042721
Status: UNCONFIRMED → NEW
Ever confirmed: true
Strange, is it not, that in the very build that bug 130855 is seemingly fixed, this bug appears.
blizzard, would this be from your checkin for bug 129591?
Yep wfm in 2002-04-27-07-trunk, broken in 2002-04-27-21-trunk, the other way round wrt bug 130855.
*** Bug 140873 has been marked as a duplicate of this bug. ***
*** Bug 140923 has been marked as a duplicate of this bug. ***
This is a feature. The fact that it worked before was only a side effect of the fact that popup windows didn't block events to the parent window.
If it indeed a feature, it seems inconsistent with every other UI I have tried. I suppose for popup context menus, it makes sense for them to prevent events from reaching the parent window. But in the case of a pulldown menu on a menu bar, it really ought to be possible to move the mouse across the other menus on the menubar and have them pull down automatically.
Jason, have you ever tried the NS4/Unix UI? It works basically the same way... The one difference is that in Mozilla if I click File then click Edit all that happens is the File menu is closed. In NS4, the File menu is closed and Edit is opened....
I have used NS4 for Unix, and you're right, it does not pop up the menus as you mouseover them, UNLESS you click and hold the mouse button down and move it across the menubar. Most modern GUIs on Unix (anything Qt or gtk+) do not require you to hold the mouse button down, though. I think the current behaviour is awkward because I really like to be able to quickly scan menus for something I am looking for. Often I forget where something that I don't use frequently is. As it is now, I'd have to click the menu where I think it is, if it isn't there, click outside it, then click a different menu, and repeat the clicking until I find the option.
Yeah, it's sub-optimal but we would need to change some APIs in order to get it working the right way. Of course, in order to make menus a good bit faster we need to fix the APIs anyway. I'll open another bug.
*** Bug 141512 has been marked as a duplicate of this bug. ***
*** Bug 141721 has been marked as a duplicate of this bug. ***
*** Bug 141943 has been marked as a duplicate of this bug. ***
> ------- Additional Comment #4 From Brian Ryner 2002-04-29 00:49 ------- > blizzard, would this be from your checkin for bug 129591? Yes, it is, see dup bug 141943. Backing out the fix for bug 129591 fixes this regression. Very visible, very annoying regression. -> critical
Assignee: hyatt → blizzard
Severity: normal → critical
I am not sure if this is the same bug, but if it is, it completely disproves the "this is a feature" approach. Reproducible: always. 1) go do the "bookmark" icon on the left of the URL bar and start draggning it. 2) Drag it past any folder item in the personal bookmarks toolbar. Actual: the folder submenu pops up. 3) Challenge: find the way to get rid of that menu. Actual: nothing gets rid of it! If I drop the dragged item (no matter whether in menu or ouside of it), nothing happens. If I press "Esc", menu disappears, but then appears back right away. If I click in a parent window, menu disappears, but then appears back right away. The only way I know to kill it is to use the fact that in a double click the second click gets to the parent window (as a signle click!) to open the File menu and activate the "Close" (or "Quit") menu item. Expected: either of the 3: a) Menu never pops up in the first place, even when I drag past the folder. b) Something interesting happens when I drop the bookmark into the menu. c) Menu goes away when I drag past it. Is it this "feature" that prevents "c" from happening?
P.S. BuildId 2002050205 on RedHat 7.2+updates. P.P.S. Also, even if you close the offending browser window, the rest of Mozilla starts acting "funny" - basically, the contents of the browser windows (including the message body pane in MailNews) gets frosen - no matter what you do they keep displaying the same thing; but the UI appears to be working normally...
Aleksey, that is bug 96504.
That personal toolbar bug is bug 96504 and has nothing to do with this. OK, so this isn't a feature. It's a bug. See the bug this depends on this one for what needs to happen to fix it.
*** Bug 142530 has been marked as a duplicate of this bug. ***
*** Bug 142687 has been marked as a duplicate of this bug. ***
Summary: unnormal behavior when leaving menu → unnormal behavior when leaving menu (menus don't open when hovered while another menu is open)
*** Bug 143221 has been marked as a duplicate of this bug. ***
Why is it critical? You just have to click another time. Not very annoying compared to some dataloss bugs.
Because of the way some people use menus. I often open an arbitary menu in the area of the one I need, and only when I clicked, I read the menu texts and mouse over to the menu I actually want. When I want to open Edit, I usually open View first and then mouse over to Edit. Same for Window -> Tools. Multiply that by the times the menus are used daily and you have a stop-ship bug (IMO).
Your way to open menus is very inconsistent. If you want to open Edit, click on Edit, not on View! I still don't see why the bug is critical. There is a very easy workaround, which doesn't take time. Some dataloss bugs or bugs preventing from displaying a document are not even declared as critical. IMHO, I see this bug as a minor one.
This patch stops dropping motion events if there's a rollup listener and the event is not on a popup window. This means that content windows will get motion events again.
Comment on attachment 82921 [details] [diff] [review] patch firstname.lastname@example.org, looks quite safe
Attachment #82921 - Flags: review+
Patch works well. Thanks, blizzard! :-)
Comment on attachment 82921 [details] [diff] [review] patch sr=shaver.
Attachment #82921 - Flags: superreview+
Comment on attachment 82921 [details] [diff] [review] patch a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #82921 - Flags: approval+
Checked into the truck and the 1.0 branch.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
VERIFIED FIXED on the trunk -- thanks blizzard!
Status: RESOLVED → VERIFIED
filed http://bugscape.mcom.com/show_bug.cgi?id=15548 to get this fixed on the commercial PR1 branch.
If this gets fixed on the PR1 branch, please remember to fix bug 143607 (caused by this fix) there as well.
This patch also apparently caused bug 155018 (or at least one of the two or three bugs needed to have that bug be annoying).
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.