With various items on the browser window - if the mouse is moved across them, and then moved outside of the browser window... that item will remain highlighted until either the mouse moves back inside the window, or moves over the respective item again, and then off (without repeating the out-of-window motion). Only the back button and things in that area suffer from not unhighlighting until the mouse is moved over them again. Otherwise... things are normally unhighlighted simply when the mouse returns to the window (21st March Build)

-> XPToolkit Widgets. ANother one I don't see but it could be because I'm in windows.

I can't reproduce this on linux with 2000032209 opt comm bits. I'm going to mark this WORKSFORME, but endah@dircon.co.uk, if you could provide some more detail on how specifically I could reproduce this, then please REOPEN this bug. Thanks.

Comments from endah@dircon.co.uk by email | Place the mouse pointer over the vertical rectangular block next to the | 'back' button. Now, with that highlighted, move the mouse pointer straight | off the edge of the browser window and onto the desktop behind it. Almost | every single time I do this, the block remains highlighted (in NT or Linux). | It's probably worth noting that the speed with which I do this affects the | results with other highlightable areas. With this rectangular block, | though, results seem to be consistent. | | Basically - find any part of the user interface that has a highlighted mode - | highlight it, and move the mouse pointer onto the desktop as fast as possible. Okay, I do see this on mac, win32 and linux, for today's builds (20000327nn). Try the above with the toolbar grippy beside the Back button, on with any of the popups in the bottom taskbar. Basically, it appears that these elements are not receiving onmouseout events when the the onmouseout is coincident with leaving the entire window. [That may not be what is actually happening, but that's what it looks like on the surface]. Reopening this bug ... (a bit of fit and finish work).

I can reproduce it using 32809 verification build on Linux, but I think this is Joki's area, reassigning.

I can't see this on Windows 95 - can anyone reproduce now? Gerv

Marking WORKSFORME in 20000514. Gerv

verified worksform mac/linux/win32 20000519