Closed
Bug 140767
Opened 23 years ago
Closed 23 years ago
unnormal behavior when leaving menu (menus don't open when hovered while another menu is open)
Categories
(Core :: XUL, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: mrasp, Assigned: blizzard)
References
Details
(Keywords: platform-parity, Whiteboard: [Hixie-P0])
Attachments
(1 file)
722 bytes,
patch
|
jesup
:
review+
shaver
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
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).
Comment 3•23 years ago
|
||
Strange, is it not, that in the very build that bug 130855 is seemingly fixed, this bug appears.
Comment 5•23 years ago
|
||
Yep wfm in 2002-04-27-07-trunk, broken in 2002-04-27-21-trunk, the other way round wrt bug 130855.
Assignee | ||
Comment 8•23 years ago
|
||
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.
Comment 9•23 years ago
|
||
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.
![]() |
||
Comment 10•23 years ago
|
||
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....
Comment 11•23 years ago
|
||
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.
Assignee | ||
Comment 12•23 years ago
|
||
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.
Comment 16•23 years ago
|
||
> ------- 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
Updated•23 years ago
|
Keywords: mozilla1.0
Comment 17•23 years ago
|
||
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?
Comment 18•23 years ago
|
||
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...
Assignee | ||
Comment 20•23 years ago
|
||
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.
Updated•23 years ago
|
Keywords: pp
Summary: unnormal behavior when leaving menu → unnormal behavior when leaving menu (menus don't open when hovered while another menu is open)
Whiteboard: [Hixie-P0]
Comment 24•23 years ago
|
||
Why is it critical? You just have to click another time. Not very annoying compared to some dataloss bugs.
Comment 25•23 years ago
|
||
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).
Comment 26•23 years ago
|
||
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.
Assignee | ||
Comment 27•23 years ago
|
||
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 28•23 years ago
|
||
Comment on attachment 82921 [details] [diff] [review] patch r=rjesup@wgate.com, looks quite safe
Attachment #82921 -
Flags: review+
Comment 30•23 years ago
|
||
Comment on attachment 82921 [details] [diff] [review] patch sr=shaver.
Attachment #82921 -
Flags: superreview+
Comment 31•23 years ago
|
||
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+
Comment 33•23 years ago
|
||
VERIFIED FIXED on the trunk -- thanks blizzard!
Status: RESOLVED → VERIFIED
Comment 34•23 years ago
|
||
filed http://bugscape.mcom.com/show_bug.cgi?id=15548 to get this fixed on the commercial PR1 branch.
![]() |
||
Comment 35•23 years ago
|
||
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.
Description
•