All users were logged out of Bugzilla on October 13th, 2018

Moving the mouse quickly causes wrong menu to be displayed.

ASSIGNED
Assigned to

Status

()

--
minor
ASSIGNED
18 years ago
10 years ago

People

(Reporter: vectro, Assigned: mikepinkerton)

Tracking

({helpwanted})

Trunk
Future
x86
Linux
helpwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
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

18 years ago
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!
(Reporter)

Comment 2

18 years ago
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

18 years ago
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?
(Reporter)

Comment 4

18 years ago
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

18 years ago
WORKSFORME
Platform: PC
OS: Linux 2.2.16
Mozilla Build: 2001011508

Comment 6

18 years ago
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). 
(Reporter)

Comment 7

18 years ago
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

18 years ago
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).
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 9

18 years ago
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.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Keywords: helpwanted
Target Milestone: --- → Future

Comment 10

18 years ago
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

17 years ago
Are anyone still seeing this bug?

Updated

10 years ago
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.