Bug 1734705 Comment 8 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
The code you're changing is in `[bool nsAppShell::ProcessNextNativeEvent(bool aMayWait)](https://hg.mozilla.org/mozilla-central/file/4b74bccdf4dc16e7f6dfbc2aea4afa6d1d02d656/widget/cocoa/nsAppShell.mm#l631)`. The change you have in mind basically chops off the second part of the [`if (aMayWait)` conditional](https://hg.mozilla.org/mozilla-central/file/4b74bccdf4dc16e7f6dfbc2aea4afa6d1d02d656/widget/cocoa/nsAppShell.mm#l677). With this change, `nsAppShell::ProcessNextNativeEvent()` will never process a native event while `aMayWait` is `false`.

I don't know whether this will make trouble. It might even be an improvement. But I have a suggestion that's less radical and might still solve your problem:

        diff --git a/widget/cocoa/nsAppShell.mm b/widget/cocoa/nsAppShell.mm
        --- a/widget/cocoa/nsAppShell.mm
        +++ b/widget/cocoa/nsAppShell.mm
        @@ -693,7 +693,7 @@ bool nsAppShell::ProcessNextNativeEvent(
               EventRef currentEvent =
                   AcquireFirstMatchingEventInQueue(currentEventQueue, 0, NULL, kEventQueueOptionsNone);
               if (!currentEvent) {
        -        continue;
        +        break;
               }
               EventAttributes attrs = GetEventAttributes(currentEvent);
               UInt32 eventKind = GetEventKind(currentEvent);

Your problem isn't caused by calling `AcquireFirstMatchingEventInQueue()` directly -- there's another call (below) that your patch doesn't remove. The real question is why I avoided calling `[NSApp nextEventMatchingMask:...]` when `aMayWait` is false. I no longer have a clear memory of what I was thinking when I wrote my patch for bug 996848. But I left copious notes there and in my source code. As best I can tell, the best overall summary is [in this code comment](https://hg.mozilla.org/mozilla-central/file/4b74bccdf4dc16e7f6dfbc2aea4afa6d1d02d656/widget/cocoa/nsAppShell.mm#l663).
Revision 1 by
on 
The code you're changing is in [`bool nsAppShell::ProcessNextNativeEvent(bool aMayWait)`](https://hg.mozilla.org/mozilla-central/file/4b74bccdf4dc16e7f6dfbc2aea4afa6d1d02d656/widget/cocoa/nsAppShell.mm#l631). The change you have in mind basically chops off the second part of the [`if (aMayWait)` conditional](https://hg.mozilla.org/mozilla-central/file/4b74bccdf4dc16e7f6dfbc2aea4afa6d1d02d656/widget/cocoa/nsAppShell.mm#l677). With this change, `nsAppShell::ProcessNextNativeEvent()` will never process a native event while `aMayWait` is `false`.

I don't know whether this will make trouble. It might even be an improvement. But I have a suggestion that's less radical and might still solve your problem:

        diff --git a/widget/cocoa/nsAppShell.mm b/widget/cocoa/nsAppShell.mm
        --- a/widget/cocoa/nsAppShell.mm
        +++ b/widget/cocoa/nsAppShell.mm
        @@ -693,7 +693,7 @@ bool nsAppShell::ProcessNextNativeEvent(
               EventRef currentEvent =
                   AcquireFirstMatchingEventInQueue(currentEventQueue, 0, NULL, kEventQueueOptionsNone);
               if (!currentEvent) {
        -        continue;
        +        break;
               }
               EventAttributes attrs = GetEventAttributes(currentEvent);
               UInt32 eventKind = GetEventKind(currentEvent);

Your problem isn't caused by calling `AcquireFirstMatchingEventInQueue()` directly -- there's another call (below) that your patch doesn't remove. The real question is why I avoided calling `[NSApp nextEventMatchingMask:...]` when `aMayWait` is false. I no longer have a clear memory of what I was thinking when I wrote my patch for bug 996848. But I left copious notes there and in my source code. As best I can tell, the best overall summary is [in this code comment](https://hg.mozilla.org/mozilla-central/file/4b74bccdf4dc16e7f6dfbc2aea4afa6d1d02d656/widget/cocoa/nsAppShell.mm#l663).
Revision 2 by
on 
The code you're changing is in [`bool nsAppShell::ProcessNextNativeEvent(bool aMayWait)`](https://hg.mozilla.org/mozilla-central/file/4b74bccdf4dc16e7f6dfbc2aea4afa6d1d02d656/widget/cocoa/nsAppShell.mm#l631). The change you have in mind basically chops off the second part of the [`if (aMayWait)` conditional](https://hg.mozilla.org/mozilla-central/file/4b74bccdf4dc16e7f6dfbc2aea4afa6d1d02d656/widget/cocoa/nsAppShell.mm#l677). With this change, `nsAppShell::ProcessNextNativeEvent()` will never process a native event while `aMayWait` is `false`.

I don't know whether this will make trouble. It might even be an improvement. But I have a suggestion that's less radical and might still solve your problem:

        diff --git a/widget/cocoa/nsAppShell.mm b/widget/cocoa/nsAppShell.mm
        --- a/widget/cocoa/nsAppShell.mm
        +++ b/widget/cocoa/nsAppShell.mm
        @@ -693,7 +693,7 @@ bool nsAppShell::ProcessNextNativeEvent(
               EventRef currentEvent =
                   AcquireFirstMatchingEventInQueue(currentEventQueue, 0, NULL, kEventQueueOptionsNone);
               if (!currentEvent) {
        -        continue;
        +        break;
               }
               EventAttributes attrs = GetEventAttributes(currentEvent);
               UInt32 eventKind = GetEventKind(currentEvent);

Your problem isn't caused by calling `AcquireFirstMatchingEventInQueue()` directly -- there's another call (below) that your patch doesn't remove. The real question is why I avoided calling `[NSApp nextEventMatchingMask:...]` and `[NSApp sendEvent:]` when `aMayWait` is false. I no longer have a clear memory of what I was thinking when I wrote my patch for bug 996848. But I left copious notes there and in my source code. As best I can tell, the best overall summary is [in this code comment](https://hg.mozilla.org/mozilla-central/file/4b74bccdf4dc16e7f6dfbc2aea4afa6d1d02d656/widget/cocoa/nsAppShell.mm#l663).

Back to Bug 1734705 Comment 8