NSPopover content view controller does not receive mouseDown/Up when reduced transparency accessibility setting is enabled

Originator:chris.bracken
Number:rdar://FB12050037 Date Originated:2023-03-10
Status:Potential fix identified - macOS 13.3.1 Resolved:
Product:macOS / AppKit Product Version:13.2.1
Classification:Incorrect/Unexpected Behavior Reproducible:Always
 
mouseDown/mouseUp events are not correctly forwarded up the responder chain for views nested inside an NSPopover when the Reduced Transparency accessibility setting is enabled prior to app startup.

## Overview
The linked repro app includes an NSViewController subclass, MyViewController, that simply embeds an NSView and adds a mouseDown:(NSEvent*) handler that logs a string to the console.

https://github.com/cbracken/PopoverRepro

## Expected behaviour
In all cases, clicking within the bounds of the view managed by MyViewController should trigger a mouseDown: call on the view controller.

## Actual behaviour
When the Reduce Transparency accessibility setting is enabled and the view is the content view of an NSPopover, mouseDown: is not called on clicks in the view managed by MyViewController.

When the Reduced Transparency accessibility setting is disabled, mouseDown: is called regardless of whether the view is the content view of an NSPopover or an NSWindow.

When the view is the content view of an NSWindow, mouseDown: is called regardless of whether the Reduce Transparency accessibility setting is enabled.

## Repro steps
1. Open macOS System Settings > Accessibility > Display.
2. Enable the Reduce Transparency setting.
3. From Xcode, build and launch the app.
4. Click the main window one or more times. "MyViewController got mouseDown!" will be logged in the debug console.
5. Click the heart status bar icon in the menu bar to open a view of the same type in an NSPopover.
6. Click the contents of the popover that appears. Note that nothing is logged to the debug console.

Repeat these steps with the _Reduce Transparency_ setting disabled to see that mouse clicks are logged for clicks in both the main window and the popover.

## Notes
No notable differences are noted between the working and non-working scenario when probing the responder chain. In both cases, the responder chain appears to be:
```
<PopoverRepro.MyView: 0x11a204e10>
<PopoverRepro.MyViewController: 0x600002e36a00>
<NSPopover: 0x600003714630, animates=1, behavior=0>
<_NSPopoverWindow: 0x11a205040>
<NSStatusBarWindow: 0x14b89bb60>
```

`MyView`, an `NSView` subclass, does have its `mouseDown:` method called, and probing self.nextResponder during that call shows that the next responder is indeed `MyViewController`; however, the default implementation of calling `mouseDown:` on `super` results in no call to the view controller's `mouseDown:` method. This bug repros even if you use a plain `NSView`, but `MyView` exists to demonstrate that the first responder's `mouseDown:` is called, but that the view controller's is not under the above conditions.

Adding a breakpoint on all `mouseDown:` methods suggests that `NSView` itself may not have a `mouseDown:` implementation, but its superclass `NSResponder` does, and that implementation appears to be walking a responder chain and triggering `forwardMethod` calls which presumably send the `mouseDown:` message on each responder. It does seem to iterate over the correct number of items in the responder chain, before hitting `_NSPopoverWindow`'s `mouseDown:` implementation, which _does_ get called.

One notable difference in the view hierarchy is that when reduced transparency is enabled, an `_NSPopoverFrameAXBackgroundView` appears in the view hierarchy as a peer of `MyViewController`. This has no effect on the responder chain, however.

Comments

Appears to have been fixed

Status was updated to "Potential fix identified - macOS 13.3.1"

I've tested on macOS 14.3 and this issue appears to be resolved.

By chris.bracken at Jan. 24, 2024, 8:52 p.m. (reply...)

Status was updated to "Potential fix identified - For a future OS update"

By chris.bracken at April 27, 2023, 6:57 p.m. (reply...)

Just to be clear - the "Reduce Transparency" setting must be enabled before launching the app. Changing it while the app is running doesn't appear to trigger the behaviour.

By chris.bracken at March 13, 2023, 7:37 p.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!