Last Comment Bug 675208 - Use NSTrackingArea for mouse event targeting
: Use NSTrackingArea for mouse event targeting
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Widget: Cocoa (show other bugs)
: Trunk
: All Mac OS X
: -- normal (vote)
: mozilla8
Assigned To: Markus Stange [:mstange] [away until June 27]
:
Mentors:
Depends on: 678691
Blocks: 560766 611068
  Show dependency treegraph
 
Reported: 2011-07-29 07:50 PDT by Markus Stange [:mstange] [away until June 27]
Modified: 2011-08-13 13:00 PDT (History)
7 users (show)
mstange: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
v1 (48.92 KB, patch)
2011-07-29 07:50 PDT, Markus Stange [:mstange] [away until June 27]
jaas: review+
Details | Diff | Review

Description Markus Stange [:mstange] [away until June 27] 2011-07-29 07:50:50 PDT
Created attachment 549374 [details] [diff] [review]
v1

We could have done this ever since we dropped 10.4 compatibility. I don't know why I didn't think of this sooner.

The current mouse move event targeting setup has two drawbacks:
 1. It's unnecessarily CPU-intensive because we traverse all windows on the
    screen on every mouse move, even if we're not the active application, and
    even if all our own windows are hidden behind other apps' windows.
 2. The system wide mouse move event monitor might be the reason for
    bug 611068. (If it's not, the mouse down event tap is.)

We're taking these measures because [window setAcceptsMouseMoveEvents:YES] will always send the event to the current first responder, no matter which window the mouse is actually over. It also doesn't by default send events when our app is inactive.

Well, NSTrackingArea changes all that and actually behaves like you'd expect it to: Mouse move events are always and only sent to the tracking area under the mouse, and you can even specify that you'd like to get events regardless of app activation status (NSTrackingActiveAlways).
NSTrackingAreas have one imperfection: You don't get a mouse enter event if the mouse is already inside the area that's being created. But that's not so bad because we can correct the mouse enter state as soon as the mouse moves.

Most of this patch is very straightforward: There's one tracking area per window, and it gets recreated whenever the window size changes. As for the rest:
 - The sendEvent override on PopupWindow has been unnecessary ever since we
   dropped 10.4 compatibility. I've extensively tested this ages ago but never
   got around to filing a bug about it. However, now it's even actively
   harmful because it routes mouse events to the first responder, so they
   don't get to the tracking area. That's why I'm removing it.
 - The testing story is tricky. Synthesizing mouse moves and getting tracking
   area events seems impossible, so the test simulates the expected events.
   I've also removed those parts of the test that sent mouse events to windows
   that are not under the mouse because those cases don't occur with tracking
   areas.

I've tested this patch on 10.6 and 10.7 and couldn't find any regressions. I've gone through all the bugs in the blame range of the code I'm removing.
This build contains the patch: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mstange@themasta.com-d728455128c0/try-macosx64/firefox-8.0a1.en-US.mac.dmg
Comment 1 Josh Aas 2011-08-07 16:40:07 PDT
This patch replaces some of the most unfortunate code in Cocoa widgets. Thanks for doing this!
Comment 2 Markus Stange [:mstange] [away until June 27] 2011-08-08 07:48:16 PDT
http://hg.mozilla.org/integration/mozilla-inbound/rev/fee47b64b378
Comment 3 Markus Stange [:mstange] [away until June 27] 2011-08-09 04:17:52 PDT
I've backed this out to see whether it's responsible for the 60% Trace Malloc MaxHeap increase that can be seen on http://mzl.la/paIasC
http://hg.mozilla.org/integration/mozilla-inbound/rev/6b943c8d7c5e
http://hg.mozilla.org/integration/mozilla-inbound/rev/ca13b9114ce6
Comment 4 :Ehsan Akhgari (busy, don't ask for review please) 2011-08-09 08:54:09 PDT
http://hg.mozilla.org/mozilla-central/rev/fee47b64b378

The backout changeset has not made it to m-c yet.
Comment 5 Markus Stange [:mstange] [away until June 27] 2011-08-10 03:55:39 PDT
And relanded on inbound because it wasn't responsible. (Bug 668195 is.)
http://hg.mozilla.org/integration/mozilla-inbound/rev/9c4561248f89
Comment 6 :Ehsan Akhgari (busy, don't ask for review please) 2011-08-10 08:23:49 PDT
The backout made it to m-c:

http://hg.mozilla.org/mozilla-central/rev/6b943c8d7c5e
Comment 7 Mounir Lamouri (:mounir) 2011-08-11 04:30:43 PDT
Merged:
http://hg.mozilla.org/mozilla-central/rev/9c4561248f89

Note You need to log in before you can comment on or make changes to this bug.