425556 - Mouse-moved events sent to background windows when popup window is displayed

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Attachment: Proposed patch

Comment 2

[Steven Michaud [:smichaud] (Retired)]

Tryserver build made with the patch from comment #1:

https://build.mozilla.org/tryserver-builds/2008-03-28_10:[e-mail]-bugzilla425556/[e-mail]

Comment 3

[Samuel Sidler (old account; do not CC)]

Let's get this in 1.9.1.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

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).

Comment 5

[Josh Aas]

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.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 8

[Markus Stange [:mstange]]

Fixed by bug 443178.

Comment 9

[Markus Stange [:mstange]]

Tests were added in bug 470845.