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)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: mrasp, Assigned: blizzard)

References

Details

(Keywords: platform-parity, Whiteboard: [Hixie-P0])

Attachments

(1 file)

patch
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).
The used mozilla build was: 2002042721
confirmed....
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.
Depends on: 141198
*** 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
Blocks: Beonex
Severity: normal → critical
Keywords: mozilla1.0
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.
Blocks: pt-menus
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. ***
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]
*** 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.
Attached patch patch — — Splinter Review 
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

r=rjesup@wgate.com, 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+
Blocks: 138000
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: 23 years ago
Keywords: fixed1.0.0
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.
No longer blocks: Beonex
This patch also apparently caused bug 155018 (or at least one of the two or
three bugs needed to have that bug be annoying).
No longer blocks: pt-menus
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.

Attachment

General

Creator:
Created:
Updated:
Size: