Closed Bug 425556 Opened 14 years ago Closed 13 years ago

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


(Core :: Widget: Cocoa, defect)

Not set





(Reporter: smichaud, Assigned: mstange)



(Whiteboard: [fixed by bug 443178])


(1 file)

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


   Open one of the Places menus in the second window (e.g. Smart


   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.
Attached patch Proposed patchSplinter Review
Assignee: joshmoz → smichaud
Attachment #312305 - Flags: review?(joshmoz)
Flags: wanted1.9.0.x?
Let's get this in 1.9.1.
Flags: wanted1.9.1?
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x-
Flags: wanted1.9.1? → wanted1.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).
Flags: wanted1.9.1- → wanted1.9.1?
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.
Flags: wanted1.9.1? → wanted1.9.1+
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

So, aside from the issue with sLastViewEntered, I think this is a

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.
Depends on: 443178
Attachment #312305 - Flags: review?(joshmoz)
Flags: wanted1.9.2+
Flags: wanted1.9.1-
Flags: wanted1.9.1+
Fixed by bug 443178.
Assignee: smichaud → mstange
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by bug 443178]
Target Milestone: --- → mozilla1.9.3a1
Tests were added in bug 470845.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.