I'm not sure how serious this is, but since I've seen it I think I should report it. Normally, mouse-moved events have no effect on browser windows that don't currently have the keyboard focus (aren't key), even when the browser has the application focus. (This seems to be normal behavior on the Mac, and also happens with Safari.) But they _do_ have an effect (are sent to Gecko and processed by it) if a popup window of any kind is open, even over a different window. There are a number of ways to illustrate this. Perhaps the easiest is to use a testcase from bug 297080 ("testcase2", attachment 290444 [details]), which has a large object that changes color when you mouse over it. 1) Open two browser windows that either don't overlap, or only partially overlap. Open attachment 290444 [details] in one of them (the "first window"), and click on the second one (the "second window") to give it the keyboard focus. 2) Move (don't drag) the mouse over the first window (the one in the background) -- hover over various browser-chrome objects and over the object from testcase2. Notice that they don't change appearance as you do this. 3) Open a context menu over either window (but without giving the first window they keyboard focus). or Open one of the Places menus in the second window (e.g. Smart Bookmarks). or Type a 'w' into the location bar, to display a drop-down list of recently visited web sites. 4) While any of these popup windows is displayed, move the mouse over the first window. Notice that parts of it do change appearance as you mouse over them.

Tryserver build made with the patch from comment #1: https://build.mozilla.org/tryserver-builds/2008-03-28_10:26-smichaud@pobox.com-bugzilla425556/smichaud@pobox.com-bugzilla425556-firefox-try-mac.dmg

Let's get this in 1.9.1.

Josh, this really should be at least wanted1.9.1. It's got a simple fix (though the patch does need to be updated, and I probably shouldn't reset sLastViewEntered).

I originally marked it wanted191- because I recall thinking this patch was very risky, so much so that it might already be too late in our cycle to take it. On your advice I'll + it but we need to be really careful. The "right" behavior here might be clear, but a lot of people wrote code against our current mouse move event behavior in cocoa widgets.

What I report in comment #0 is clearly a bug. It's hard to imagine anybody relying on that behavior. My fix is simple and (I think) precisely targeted at this bug (it's unlikely to effect other operations than those described in comment #0). So, aside from the issue with sLastViewEntered, I think this is a no-brainer. If we're worried about compatibility issues, lets land this right away (before the 3.1 beta). If there are any, that should give us time to find them.

Another bug has surfaced (bug 455679) that can probably be resolved using the same strategy my patch (attachment 312305 [details] [diff] [review]) uses for this bug.

Fixed by bug 443178.

Tests were added in bug 470845.