druid: On master branch, Cmd+Q doesn't quit app, but emits warning instead
I recently switched from v0.7.0 to master. I recognized that Cmd+Q does not quit the app anymore. This happens not only in my project but also in the example (at least, flex example). Instead, it emits a warning every time I submit the keystroke, apparently related to OS layer:
cargo run --example flex
2021-04-10 13:37:22.456 flex[74291:7719784] +[NSView doCommandBySelector:]: unrecognized selector sent to class 0x7fff885efa08
This happens only in master. In v0.7.0, I can quit the app with Cmd+Q without any warning.
Environment
- druid master (2c5d73c8426f90d2a1ede9fdd3b5cb7bee57f108)
- macOS Big Sur 11.2.3 (Intel)
I can provide further environmental information if needed.
About this issue
- Original URL
- State: open
- Created 3 years ago
- Comments: 21 (15 by maintainers)
Commits related to this issue
- [macos] Fix issue with missing default menu This has been an issue since the menu refactor, apparently, but i hadn't bothered to track it down until now. With this fix, macos windows will have a sta... — committed to linebender/druid by cmyr 2 years ago
- [macos] Fix issue with missing default menu This has been an issue since the menu refactor, apparently, but i hadn't bothered to track it down until now. With this fix, macos windows will have a sta... — committed to linebender/druid by cmyr 2 years ago
- [macos] Fix issue with missing default menu This has been an issue since the menu refactor, apparently, but i hadn't bothered to track it down until now. With this fix, macos windows will have a sta... — committed to xarvic/druid by cmyr 2 years ago
- [macos] Fix issue with missing default menu This has been an issue since the menu refactor, apparently, but i hadn't bothered to track it down until now. With this fix, macos windows will have a sta... — committed to xarvic/druid by cmyr 2 years ago
I was looking into this a bit the other day, and I have a bit of a view of what’s going wrong. The key error is in this bit of code. This attempts to get the superclass of the current object, then tries to call
doCommandBySelectoron it. This doesn’t make sense becausedoCommandBySelectoris an instance method, not a class method. The code attempts to send a message to the class itself, not the instance, which is what causes the crash in #1720 .I assume the intent of that snippet was to achieve the equivalent of
which calls
doCommandBySelectoron the current instance, but attempts to call the implementation from the superclass.The proper translation to rust would be
However, this still doesn’t make much sense. Apple’s documentation makes it clear that implementations of
doCommandBySelector:should not call super.I’m not quite sure what the intended behavior was here and so I’m not sure what the correct replacement is, but it definitely doesn’t seem correct to call the super.
Hope that helps some!
@nathanwhit Forwarding the message up the chain is what NSResponder does and this is trying to achieve similar. That it’s currently being forwarded to the wrong object (class instead of instance) is a bit of a red herring. As was pointed out above the message is a no-op so it doesn’t really matter where it gets forwarded.
The issue is that the default macOS menu contains and registers the Cmd+Q hotkey. Without the menu the hotkey is unbound and nothing happens. There’s basically two choices: always create the default menu (or a menu with a Cmd+q -> Quit item) or register the hotkey separately. For the latter registering a callback with
addLocalMonitorForEventsMatchingMaskis probably the way to go.https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/EventOverview/MonitoringEvents/MonitoringEvents.html
Ok, this comes from here:
This works as expected for me on 10.15.7, so I think this is a change in macOS?
Repros here too.