It's possible, by mousing over toolbar buttons quickly, to leave a toolbar button in the 'mouseover' state even when the mouse is elsewhere. This is not just a redraw problem: hiding and showing the window causes the button still to be drawn in the mouseover state.

reassigning to evaughan as p4 for m7

If you move the mouse out of the window the titled buttons do not get a mouse exited event. Dup of bug 3175 *** This bug has been marked as a duplicate of 3175 ***

This is not the same bug as 3175. This problem can be reproduced without the mouse ever leaving the window area.

sfraser, is this Mac only? Or all platforms?

This seems to have been fixed; I can't reproduce it on any platform now.

Reopening. I can cause this to happen still, on Mac.

This actually happens on all platforms. It's just more apparent on platforms which are less responsive.

Moving out based on priority

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

This seems to be a problem with frames. Because 4.x does it also, despite the speed of the machine. Events are listened to seperately in each frame or iframe, so reaction time is afected not because of the machine but because of seperate frame object listener transitions. -just a thought.

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

Just marked my version ( http://bugzilla.mozilla.org/show_bug.cgi?id=6767 ) as a dupe, pinkerton had some ideas from that one. Attaching below - look at 6767 if you get a chance ------- Additional Comments From pinkerton@netscape.com 05/27/99 16:07 ------- this happens because gecko is losing events somehow. It seems that when the mouse is moving quickly, the OS sampling rate for mouse-moved events is too slow, so one event is over the button, hence the bevel border, and the next sample is when the mouse is in the menu bar or in another presShell. As a result, the presShell with the toolbar doesn't get the "mouseExit" event.

if you look at toolbarTest1.xul you can mouse over these buttons as fast as possible, you will not get them to stick. Why? because the content are is larger, the buttons are sluggish but don't stick. now mouse over to the grippies. they will not stick no matter where you are. they also have very acceptable UI speed. i am testing on a pentium 75 here and the grippies are as fast if not faster than my mozilla 4.x native UI. This is the key to the problem. if the grippies can perform this fast then the buttons can also.

You seem to have problems with mouse event distribution related to the difference of global / local mouse tracking. Your presShells seem to be responsible for handling local (restricted to their own visible area) mouse tracking. So some other modul of Mozilla will be responsible for global mouse tracking and thus for notifying the local trackers of mouse events related to mouse moves crossing between them. Let the global tracker track an identifier of the current local tracker and notify both the leaved and the entered local tracker of the mouse movement when mouse moves over boundaries. For my personal Windows projects I have organized such a mouse tracking policy at global system level based on Window Handles of mouse messages. I think it should be possible to do that on Mac too.

Moving to M11. Not to hold for M10 per conversation with joki during bug triage today.

tested this with a recent Mac build; I can no longer reproduce this. I think joki may have fixed this. Marking fixed (ok'd by joki).