340592 - Make the mouse focus model more Mac-like for 1.8

Status: RESOLVED FIXED

(Core Graveyard :: Widget: Mac, defect)

Description

[Mark Mentovai]

The typical Mac focus model is that the active window responds to events like mouse-moved and mousewheel, and inactive windows generally do not.  Right now, we implement more of a Windowsy focus model, in which al windows respond to all events all the time.  (When the app is inactive, the OS doesn't deliver any events.)

Our current behavior is un-Mac-like, and there are also a few related bugs (some of which are also present in other widget toolkits): when the app or a window is activated by means other than the mouse, no new mouseover occurs; when you mouse off the edge of one (active) window over a different (inactive) window, the mouse-moved event still goes to the active (wrong) window for the first pixel using the coordinates in the inactive window.

Compare the mouse-moved and scrollwheel behavior to Safari, which does not handle mouse-moved or scrollwheel events for the non-main window.  In some ways, we'll get some of this behavior with Cocoafox because Cocoa doesn't ordinarily send these events to inactive windows.  I'm considering doing this as a 1.8-generation platform-polish improvement too.

Comment 1

[Mark Mentovai]

Attachment: Give each window its own event dispatch handler

This is handled primarily by giving each window its own event dispatch handler, instead of allowing all windows to share one global handler.  I'm concerned about behavior in some of the instances where background windows should respond to events, such as drags to and from background windows.  (Those do seem to be OK.)

Comment 2

[Mark Mentovai]

(1.8 branch patch would add to the nsPIWidgetMac_MOZILLA_1_8_BRANCH interface.)

Comment 3

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 224630 [details] [diff] [review]
Give each window its own event dispatch handler

sr=pink

as an aside....

 #if PINK_PROFILING_ACTIVATE
 if (KeyDown(0x39))	// press [caps lock] to start the profile
 	ProfileStart();
 #endif

should we just go ahead and remove these?

Comment 4

[Mark Mentovai]

Checked in on trunk, will bake a little bit before going for 1.8[.1].  I also removed the PINK_PROFILING_ACTIVATE chunks from nsMacEventHandler.

Comment 5

[Mark Mentovai]

Comment on attachment 224630 [details] [diff] [review]
Give each window its own event dispatch handler

Adding to the 1.8.1 radar.

Comment 6

[Mark Mentovai]

Attachment: 1.8[.1] branch version

mconnor says we're still on MOA today.

Comment 7

[Mark Mentovai]

Checked in on MOZILLA_1_8_BRANCH before 1.8.1b1.