Closed Bug 340592 Opened 15 years ago Closed 15 years ago

Make the mouse focus model more Mac-like for 1.8

Categories

(Core Graveyard :: Widget: Mac, defect)

1.8 Branch
PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8.1beta1

People

(Reporter: mark, Assigned: mark)

References

Details

(Keywords: fixed1.8.1)

Attachments

(2 files)

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.
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.)
Attachment #224630 - Flags: review?(joshmoz)
(1.8 branch patch would add to the nsPIWidgetMac_MOZILLA_1_8_BRANCH interface.)
Summary: Make the mouse focus model more Mac-like → Make the mouse focus model more Mac-like for 1.8
Target Milestone: --- → mozilla1.8.1beta1
Version: Trunk → 1.8 Branch
Attachment #224630 - Flags: review?(joshmoz) → review+
Attachment #224630 - Flags: superreview?(mikepinkerton)
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?
Attachment #224630 - Flags: superreview?(mikepinkerton) → superreview+
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.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment on attachment 224630 [details] [diff] [review]
Give each window its own event dispatch handler

Adding to the 1.8.1 radar.
Attachment #224630 - Flags: approval-branch-1.8.1?(mark)
Attachment #224630 - Flags: approval-branch-1.8.1?(mark)
mconnor says we're still on MOA today.
Attachment #226232 - Flags: approval-branch-1.8.1+
Checked in on MOZILLA_1_8_BRANCH before 1.8.1b1.
Keywords: fixed1.8.1
Depends on: 344006
Depends on: 344238
Depends on: 344701
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.