author | Kirk Steuber <ksteuber@mozilla.com> |
Wed, 17 Feb 2016 07:09:39 -0800 | |
changeset 293898 | a46d02998795b1e04849fc6d4fe0fbe09235fcca |
parent 293897 | 038ff8933b43546cd77633bf522bc819c6b7b4fe |
child 293899 | dbe9e023494e73887a2d30625f3bdbf8d8d5df6d |
push id | 75378 |
push user | cbook@mozilla.com |
push date | Wed, 20 Apr 2016 03:49:09 +0000 |
treeherder | mozilla-inbound@a46d02998795 [default view] [failures only] |
perfherder | [talos] [build metrics] [platform microbench] (compared to previous push) |
reviewers | josh |
bugs | 1248985 |
milestone | 48.0a1 |
first release with | nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
|
last release without | nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
|
--- a/widget/cocoa/nsAppShell.mm +++ b/widget/cocoa/nsAppShell.mm @@ -359,17 +359,17 @@ nsAppShell::ProcessGeckoEvents(void* aIn self->mRunningEventLoop = false; // The run loop may be sleeping -- [NSRunLoop runMode:...] // won't return until it's given a reason to wake up. Awaken it by // posting a bogus event. There's no need to make the event // presentable. // // But _don't_ set windowNumber to '-1' -- that can lead to nasty - // wierdness like bmo bug 397039 (a crash in [NSApp sendEvent:] on one of + // weirdness like bmo bug 397039 (a crash in [NSApp sendEvent:] on one of // these fake events, because the -1 has gotten changed into the number // of an actual NSWindow object, and that NSWindow object has just been // destroyed). Setting windowNumber to '0' seems to work fine -- this // seems to prevent the OS from ever trying to associate our bogus event // with a particular NSWindow object. [NSApp postEvent:[NSEvent otherEventWithType:NSApplicationDefined location:NSMakePoint(0,0) modifierFlags:0