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

Most upvoted comments

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 doCommandBySelector on it. This doesn’t make sense because doCommandBySelector is 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

[super doCommandBySelector: cmd]

which calls doCommandBySelector on the current instance, but attempts to call the implementation from the superclass.

The proper translation to rust would be

if let Some(superclass) = this.class().superclass() {
    unsafe { msg_send![super(this, superclass), doCommandBySelector: cmd] }
}

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 addLocalMonitorForEventsMatchingMask is probably the way to go.

https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/EventOverview/MonitoringEvents/MonitoringEvents.html

Ok, this comes from here:

Bildschirmfoto 2021-05-11 um 17 06 39

This works as expected for me on 10.15.7, so I think this is a change in macOS?

Repros here too.