65525 - Moving the mouse quickly causes wrong menu to be displayed.

Status: NEW

(Core :: XUL, defect)

Description

[vectro]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i686; en-US; 0.7) Gecko/20010105
BuildID:    2001010517

By moving the mouse after clicking on a menu and before the menu is drawn, one
can make it appear as though the wrong menu is being displayed.

Reproducible: Always
Steps to Reproduce:
1) Click on a menu, e.g. Go
2) Before menu is displayed, move mouse pointer to different menu, e.g. Bookmarks
3) Now Bookmarks menu is shown, but it's contents are actually the contents of
the Go menu.

Expected Results:  Judging by behaviour after menu is drawn, I'd say it should
draw the contents of the new (Bookmarks) menu.

Comment 1

[HJ]

Reporter, how 'fast' is your system? 
I can't reproduce this, even on a slow 350MHz Pentium II using build 2001011220
and WinNT4. I always have a menu before I can move my mouse! And Ok, the Mozilla
menu is not one of the fastest, but al least it works! 

Note: if someone is willing to change the way the menu work right now, I have
some tips for you that will speedup the menu!

Comment 2

[vectro]

I have a PII-400, running the standard XFree86 for Redhat 6.2 (3.3.6-20), and
KDE 2.0-3.

Admittedly, the menus do appear very quickly. But it is not instantanous.

Maybe the solution is to, after having drawn the menu, check where the mouse is,
and if it's under a different menu, force the switch?

Comment 3

[HJ]

What about a check if the mouse is still moving? Don't display menu's before the
mouse stops moving, will save a lot of CPU time! And what about a pref setting
for this?

Comment 4

[vectro]

Unfortunately, it is possible to stop the mouse and then start it again. E.g.,
click, then wait, then move, all before the menu is actually displayed.

But we have to follow the mouse if it moves into adjecent menus anyhow.

Comment 5

[Keyser Sose]

WORKSFORME
Platform: PC
OS: Linux 2.2.16
Mozilla Build: 2001011508

Comment 6

[John Morrison]

I also cannot reproduce this; rh6.1 gnome/enlightenment 500MHz. The first 
menu is always coming up before I can move the mouse. (Perhaps there is 
something (aside from cpu) that is slowing down menu display enough for 
you to get this effect). 

Comment 7

[vectro]

You are correct. I just tried starting X with my windowmanager set to mozilla
(e.g., it's the only thing running, and with no decorations) and the menus come
up so speedily I can't move the mouse in time.

My suspicion is that this is a memory thing; With mozilla and X the only things
running there is lots of memory to spare.

Comment 8

[John Morrison]

There is work ongoing to work on memory and perf issues, and that may be
the "fix". (Not sure if the logic is really in need of changes).

Comment 9

[vectro]

I think I'd agree with that, except if someone's system is thrashing (e.g. due
to some other application), Mozilla will be slow to respond in any case. Which
means the bug should prolly be fixed.

Comment 10

[Jesse Ruderman]

See also bug 26550.  That bug can cause the opposite problem: the first menu is 
shown although another menu appears to be active.  The problem there is that 
the first menu doesn't always "depress" the when you mousedown on it, which 
allows other menus to become "raised" while the first menu is shown if you can 
avoid triggering a mousemove or mouseup event on the first menu (by moving out 
quickly, or by starting on the edge of a menu).

Comment 11

[R.K.Aa.]

Are anyone still seeing this bug?

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.