nvda

2e4d6236 - Prevent "OrderedDict mutated during iteration" when a handler (un)registers during extension point dispatch (#20545)

Prevent "OrderedDict mutated during iteration" when a handler (un)registers during extension point dispatch (#20545) Summary of the issue: extensionPoints.Action.notify (and Filter.apply, Decider.decide, AccumulatingDecider.decide, Chain.iter) drive the HandlerRegistrar.handlers generator, which iterated self._handlers.values() directly. If a handler registered or unregistered a handler on the same extension point while being called, the underlying OrderedDict was mutated mid-iteration and Python raised RuntimeError: OrderedDict mutated during iteration, aborting the remaining handlers. I hit this in practice during development of the RDAccess add-on: on post_secureDesktopStateChange / post_sessionLockStateChanged, a handler that tears down a braille display or synth driver (which unregisters itself) during the notify crashed queueHandler.flushQueue on the _handleUserDesktop desktop-switch path. Description of user facing changes: Handlers on an extension point can now register or unregister during handler iteration without errors. Description of developer facing changes: HandlerRegistrar.handlers now yields from a snapshot of the registered handlers rather than the live collection. Handlers present when dispatch started are all still called (a just-unregistered handler still runs in that pass); newly registered handlers are picked up on the next dispatch. This matches the existing Action.notifyOnce semantics. Description of development approach: HandlerRegistrar.handlers now iterates over list(self._handlers.values()), taken before the first handler is yielded, instead of the live dict view. This mirrors the approach Action.notifyOnce already used (list(self.handlers)), and fixes every consumer of the generator with one change. As handlers now guarantees a snapshot, Action.notifyOnce was simplified to iterate self.handlers directly while unregistering each handler.