140767 - unnormal behavior when leaving menu (menus don't open when hovered while another menu is open)

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[Martin Rasp]

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 1

[Martin Rasp]

The used mozilla build was: 2002042721

Comment 2

[Boris Zbarsky [:bzbarsky]]

confirmed....

Comment 3

[Stephen Moehle]

Strange, is it not, that in the very build that bug 130855 is seemingly fixed,
this bug appears.

Comment 4

[Brian Ryner (not reading)]

blizzard, would this be from your checkin for bug 129591?

Comment 5

[Tuukka Tolvanen (sp3000)]

Yep wfm in 2002-04-27-07-trunk, broken in 2002-04-27-21-trunk, the other way
round wrt bug 130855.

Comment 6

[Gilles Durys]

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

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

[Christopher Blizzard (:blizzard)]

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

[Jason Tackaberry]

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

[Boris Zbarsky [:bzbarsky]]

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

[Jason Tackaberry]

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.

Comment 12

[Christopher Blizzard (:blizzard)]

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 13

[Boris Zbarsky [:bzbarsky]]

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

Comment 14

[Gilles Durys]

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

Comment 15

[Boris Zbarsky [:bzbarsky]]

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

Comment 16

[Ben Bucksch (:BenB)]

> ------- 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

Comment 17

[Aleksey Nogin]

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

[Aleksey Nogin]

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...

Comment 19

[Tuukka Tolvanen (sp3000)]

Aleksey, that is bug 96504.

Comment 20

[Christopher Blizzard (:blizzard)]

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.

Comment 21

[R.K.Aa.]

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

Comment 22

[R.K.Aa.]

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

Comment 23

[R.K.Aa.]

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

Comment 24

[Vincent Lefevre]

Why is it critical? You just have to click another time. Not very annoying
compared to some dataloss bugs.

Comment 25

[Ben Bucksch (:BenB)]

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

[Vincent Lefevre]

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.

Comment 27

[Christopher Blizzard (:blizzard)]

Attachment: patch

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

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 82921 [details] [diff] [review]
patch

r=[e-mail], looks quite safe

Comment 29

[Ben Bucksch (:BenB)]

Patch works well. Thanks, blizzard! :-)

Comment 30

[Mike Shaver (:shaver emeritus)]

Comment on attachment 82921 [details] [diff] [review]
patch

sr=shaver.

Comment 31

[Asa Dotzler [:asa]]

Comment on attachment 82921 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to the 1.0 branch

Comment 32

[Christopher Blizzard (:blizzard)]

Checked into the truck and the 1.0 branch.

Comment 33

[Hixie (not reading bugmail)]

VERIFIED FIXED on the trunk -- thanks blizzard!

Comment 34

[sairuh (rarely reading bugmail)]

filed http://bugscape.mcom.com/show_bug.cgi?id=15548 to get this fixed on the
commercial PR1 branch.

Comment 35

[Boris Zbarsky [:bzbarsky]]

If this gets fixed on the PR1 branch, please remember to fix bug 143607 (caused
by this fix) there as well.

Comment 36

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This patch also apparently caused bug 155018 (or at least one of the two or
three bugs needed to have that bug be annoying).