These leaks can be found with the following environment variables:
OBJC_DEBUG_MISSING_POOLS=YES LIBDISPATCH_DEBUG_MISSING_POOLS=NO

Without LIBDISPATCH_DEBUG_MISSING_POOLS=NO the libdispatch autorelease pool of last resort is disabled and it is required to prevent false positives in system libraries from showing up.

Setting a breakpoint on objc_autoreleaseNoPool gives stacks.

With all the patches from the dependent bugs applied, Firefox starts up cleanly with no warnings when running under OBJC_DEBUG_MISSING_POOLS=YES LIBDISPATCH_DEBUG_MISSING_POOLS=NO. Once I start using the keyboard, I get two warnings from the NSEventThread, but Safari has those same warnings. No more warnings happen afterwards.

I've filed FB8962868 on the NSEventThread warnings.

FB8962868: Leaks on com.apple.NSEventThread due to missing autorelease pool

AppKit
Incorrect/Unexpected Behavior

Steps to reproduce:

1. Run any graphical macOS application from Terminal, with the environment variables OBJC_DEBUG_MISSING_POOLS=YES LIBDISPATCH_DEBUG_MISSING_POOLS=NO
2. Interact with the app using the keyboard. For example, press Cmd+Tab.

Expected results:
No warnings should be printed.

Actual results:
The following warnings are printed on the console:
objc[64606]: MISSING POOLS: (0x70000a563000) Object 0x1495fd8e0 of class NSConcreteHashTable autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug
objc[64606]: MISSING POOLS: (0x70000a563000) Object 0x120489700 of class NSConcreteMapTable autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug

lldb shows the following stack:

* thread #21, name = 'com.apple.NSEventThread', stop reason = breakpoint 1.1
  * frame #0: 0x00007fff2020e755 libobjc.A.dylib`objc_autoreleaseNoPool
    frame #1: 0x00007fff2020e750 libobjc.A.dylib`AutoreleasePoolPage::autoreleaseNoPage(objc_object*) + 286
    frame #2: 0x00007fff201f3ae8 libobjc.A.dylib`objc_object::rootAutorelease2() + 32
    frame #3: 0x00007fff24c7b142 SkyLight`-[SLSecureCursorAssertionManager init] + 131
    frame #4: 0x00007fff24c7bbf2 SkyLight`__47+[SLSecureCursorAssertionManager sharedManager]_block_invoke + 13
    frame #5: 0x00007fff201a87c7 libdispatch.dylib`_dispatch_client_callout + 8
    frame #6: 0x00007fff201a996b libdispatch.dylib`_dispatch_once_callout + 20
    frame #7: 0x00007fff24c7bbde SkyLight`+[SLSecureCursorAssertionManager sharedManager] + 123
    frame #8: 0x00007fff24e69b1f SkyLight`handle_decoded_event(SLSEventRecord*, void*) + 469
    frame #9: 0x00007fff24bcc337 SkyLight`CGSDecodeEventRecord + 55
    frame #10: 0x00007fff24bcb5a3 SkyLight`CGSSnarfAndDispatchDatagrams + 694
    frame #11: 0x00007fff24e6a266 SkyLight`SLSGetNextEventRecordInternal + 278
    frame #12: 0x00007fff24cc1d11 SkyLight`SLEventCreateNextEvent + 9
    frame #13: 0x00007fff28774fab HIToolbox`PullEventsFromWindowServerOnConnection(unsigned int, unsigned char, __CFMachPortBoost*) + 45
    frame #14: 0x00007fff28774f46 HIToolbox`MessageHandler(__CFMachPort*, void*, long, void*) + 48
    frame #15: 0x00007fff20478684 CoreFoundation`__CFMachPortPerform + 250
    frame #16: 0x00007fff2044c188 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41
    frame #17: 0x00007fff2044c065 CoreFoundation`__CFRunLoopDoSource1 + 595
    frame #18: 0x00007fff2044a709 CoreFoundation`__CFRunLoopRun + 2402
    frame #19: 0x00007fff204496ce CoreFoundation`CFRunLoopRunSpecific + 563
    frame #20: 0x00007fff22de7c16 AppKit`_NSEventThread + 124
    frame #21: 0x00007fff20353950 libsystem_pthread.dylib`_pthread_start + 224
    frame #22: 0x00007fff2034f47b libsystem_pthread.dylib`thread_start + 15

All the patches in the dependent bugs have landed, and this is fixed.

We don't have CI coverage for it unfortunately.