Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Crash on macOS when the subclassing adapter is dropped while the view has key-value observers

Open
  • Is something wrong?
#823 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@RXNova is already working on this.

Since Oct 11, 2026.

  • #822 by @RXNova — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
macos, rust
Domain
backend

Research direction

Start in adapters/macos/src/subclass.rs, especially SubclassingAdapter::drop, and inspect the linked pull request #822 for current work. Reproduce with the supplied observer example and trace how the view’s Objective-C class changes while observers are registered. Done means dropping the adapter leaves observers removable without raising an exception.

Written by the indexing model from the issue text.

Description

What happens

An app that uses the macOS SubclassingAdapter is terminated by an uncaught exception every time its window is closed. In our case this is an eframe/egui 0.36 app (winit 0.30, accesskit_winit 0.32, accesskit_macos 0.26.3) on macOS 27.0.1, on a MacBook Pro with a Touch Bar (MacBookPro17,1):

*** Terminating app due to uncaught exception 'NSRangeException', reason:
'Cannot remove an observer <_NSTouchBarFinderObservation 0x…> for the key path
"nextResponder" from <WinitView 0x…> because it is not registered as an observer.'

-[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:]
-[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:]
-[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:context:]
-[_NSTouchBarFinderObservation invalidate]
___NSTouchBarFinderSetNeedsUpdateOnMain_block_invoke_2
NSDisplayCycleObserverInvoke
NSDisplayCycleFlush

I haven't checked other macOS versions or Macs without a Touch Bar.

Cause

SubclassingAdapter::drop calls object_setClass(view, prev_class) unconditionally. AppKit registers key-value observers on the window's first responder (_NSTouchBarFinderObservation, key paths nextResponder and touchBar), so by the time the adapter is dropped, the view's real class is NSKVONotifying_AccessKitSubclassOfWinitView. Resetting the class discards KVO's subclass while the observers are still registered, and AppKit's later removeObserver:forKeyPath: raises.

Tracing addObserver:/removeObserver: in a debugger showed the observers being added while the view's class was AccessKitSubclassOfWinitView, and removed after it had been reset to WinitView.

adapters/macos/src/subclass.rs on main has the same code as 0.26.3.

What should happen

Dropping the adapter shouldn't break observers that other code has registered on the view.

How to reproduce

This program does what AppKit does, with an observer of its own. With accesskit_macos 0.27.1 it aborts at the last line (fatal runtime error: Rust cannot catch foreign exceptions, aborting).

[dependencies]
accesskit = "0.25"
accesskit_macos = "0.27.1"
objc2 = "0.5.1"
objc2-app-kit = { version = "0.2.0", features = ["NSResponder", "NSView"] }
objc2-foundation = { version = "0.2.0", features = ["NSString"] }

use std::ffi::c_void;

use accesskit::{ActionHandler, ActionRequest, ActivationHandler, TreeUpdate};
use accesskit_macos::SubclassingAdapter;
use objc2::rc::Id;
use objc2::{class, msg_send, msg_send_id};
use objc2_app_kit::NSView;
use objc2_foundation::{NSObject, NSString};

struct NoTree;

impl ActivationHandler for NoTree {
    fn request_initial_tree(&mut self) -> Option<TreeUpdate> {
        None
    }
}

struct NoActions;

impl ActionHandler for NoActions {
    fn do_action(&mut self, _request: ActionRequest) {}
}

fn main() {
    let view: Id<NSView> = unsafe { msg_send_id![class!(NSView), new] };
    let adapter = unsafe {
        SubclassingAdapter::new(&*view as *const NSView as *mut c_void, NoTree, NoActions)
    };

    // Stand-in for AppKit's own observers on the first responder.
    let observer = NSObject::new();
    let key_path = NSString::from_str("nextResponder");
    let context: *mut c_void = std::ptr::null_mut();
    let _: () = unsafe {
        msg_send![&view, addObserver: &*observer, forKeyPath: &*key_path, options: 0usize, context: context]
    };

    drop(adapter);

    // Raises NSRangeException.
    let _: () = unsafe { msg_send![&view, removeObserver: &*observer, forKeyPath: &*key_path] };
}
Dominant language
Rust
Stars
1.5k
Forks
122
Avg merge
1h 14m
Merged PRs (30d)
16

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from AccessKit/accesskit

All issues in AccessKit/accesskit

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.