All users were logged out of Bugzilla on October 13th, 2018
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.
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!
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?
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?
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.
WORKSFORME Platform: PC OS: Linux 2.2.16 Mozilla Build: 2001011508
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).
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.
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
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.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
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).
Are anyone still seeing this bug?
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.