Bommels05/Mozilla
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix camino bug 311683. The earlier fix for bug 297343 introduced a short delay before the dispatch of focus/activate events on window activation. It turns out that this was bad, as you could end up with two windows which continually each come to the front ("duelling windows"). This patch makes things synchronous again, but fixes the original bug by exposing a category on NSWindow in the widget code that allows the embedder to know if a SetFocus() call is coming as a result of window activation. r=mento

Browse Source 
git-svn-id: svn://10.0.0.236/trunk@182094 18797224-902f-48f8-a5cc-f745e15eee43
This commit is contained in:
smfr%smfr.org
2005-10-12 17:38:29 +00:00
parent 9cdc37e7cb
commit 2bd5264d46
6 changed files with 45 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
mozilla/widget/src/cocoa/mozView.h
View File

@@ -75,3 +75,18 @@ class nsIWidget;
@end
//
// An informal protocol implemented by the NSWindow of the host application.
//
// It's used to prevent re-entrant calls to -makeKeyAndOrderFront: when gecko
// focus/activate events propagate out to the embedder's
// nsIEmbeddingSiteWindow::SetFocus implementation.
//
@interface NSObject(mozWindow)
- (BOOL)suppressMakeKeyFront;
- (void)setSuppressMakeKeyFront:(BOOL)inSuppress;
@end

38
mozilla/widget/src/cocoa/nsChildView.mm
View File

@@ -111,9 +111,6 @@
- (void)flushRect:(NSRect)inRect;
- (BOOL)isRectObscuredBySubview:(NSRect)inRect;
- (void)sendActivateEvent;
- (void)sendDeactivateEvent;
#if USE_CLICK_HOLD_CONTEXTMENU
// called on a timer two seconds after a mouse down to see if we should display
// a context menu (click-hold)
@@ -3451,38 +3448,29 @@ static void ConvertCocoaKeyEventToMacEvent(NSEvent* cocoaEvent, EventRecord& mac
}
- (void)viewsWindowDidBecomeKey
{
// When unhiding the app, -windowBecameKey: gets called when two bits of window
// state are incorrect (on Tiger):
//
// 1. [window isVisible] returns YES even though it's not on the screen
// 2. [NSApp keyWindow] is not the right window yet
//
// Because this state is not correct at this time, we postpone sending
// the events into gecko (which in turn propagate into the host app)
// until the next time through the event loop, when we're off this stack
// and Cocoa has got its story straight.
[self performSelector:@selector(sendActivateEvent) withObject:nil afterDelay:0];
}
- (void)viewsWindowDidResignKey
{
[self performSelector:@selector(sendDeactivateEvent) withObject:nil afterDelay:0];
}
- (void)sendActivateEvent
{
if (!mGeckoChild)
return; // we've been destroyed
return; // we've been destroyed (paranoia)
// check to see if the window implements the mozWindow protocol. This
// allows embedders to avoid re-entrant calls to -makeKeyAndOrderFront,
// which can happen because these activate/focus calls propagate out
// to the embedder via nsIEmbeddingSiteWindow::SetFocus().
BOOL isMozWindow = [[self window] respondsToSelector:@selector(setSuppressMakeKeyFront:)];
if (isMozWindow)
[[self window] setSuppressMakeKeyFront:YES];
nsFocusEvent focusEvent(PR_TRUE, NS_GOTFOCUS, mGeckoChild);
mGeckoChild->DispatchWindowEvent(focusEvent);
nsFocusEvent activateEvent(PR_TRUE, NS_ACTIVATE, mGeckoChild);
mGeckoChild->DispatchWindowEvent(activateEvent);
if (isMozWindow)
[[self window] setSuppressMakeKeyFront:NO];
}
- (void)sendDeactivateEvent
- (void)viewsWindowDidResignKey
{
if (!mGeckoChild)
return; // we've been destroyed