I first noticed this while Codex Computer History was monitoring recent
activity. I opened Anki’s Browse window, and the Anki Browser crashed
immediately as it appeared. Computer History did not click or edit anything in
Anki; its SkyComputerUseService process read the macOS accessibility hierarchy.
I later reduced the failure to this reliable route:
- Start Anki in a fresh disposable profile with sync disabled and no add-ons.
- Add a Basic card and open Browse, leaving a result row selected.
- Put Browse in native macOS fullscreen.
- Ask an authorized accessibility client to capture/read the window hierarchy.
Fullscreen reproduces the route reliably, but selected-card Browse can also
crash while windowed.
Environment:
- arm64 macOS 26.6.2
- verified crashing application: Anki 26.8.1 with bundled Qt 6.11.0
- controlled Qt 6.11.2 runtime replacement is also affected
- accessibility client: SkyComputerUseService
The crash is EXC_BAD_ACCESS / SIGSEGV on Anki’s main thread
(CrBrowserMain). The raw report’s first relevant frame is an unsymbolicated
libqcocoa.dylib offset; mapping it against the matching binary resolves it to
QMacAccessibilityElement accessibilitySelectedChildren. AppKit/HIServices
hierarchy-copy frames follow. The crash report identifies
SkyComputerUseService as the querying process.
The most useful controls are:
- fullscreen Browse with no cards and no selection: passes;
- fullscreen Browse with one selected card: crashes;
- reviewer question/answer screens: repeated hierarchy reads and transitions
pass; - replacing the complete Qt runtime with 6.11.2 does not fix selected-card
Browse.
The root cause appears to be a Qt Cocoa ownership regression, not Anki’s review
code or an add-on. Qt synthesizes native row/cell elements that reuse the parent
table’s accessibility ID. Cleanup added in Qt commit
b1ed5f656f064e553b33752f8e87d2f5b9553e38 treats those parent-managed
placeholders as owners and deletes the table interface when a selected real cell
replaces one. That invalidates the selected-cell interfaces being returned to
macOS.
I implemented a narrow upstream Qt candidate: synthesized parent-managed table
elements no longer delete the parent interface, while real cells continue to
clean up their own IDs. A native macOS regression test reproduces the table-ID
deletion on unpatched Qt and passes with the two ownership guards. The complete
native qaccessibilitymac run passes 11/11.
The candidate was then exercised with exact Anki 26.09b1 application code in a
fresh sync-disabled, zero-add-on profile. Immediate Browse opening plus the
first accessibility scan passed, followed by 25 fullscreen reads with one
selected row, five empty-to-selected model cycles, and 12 fullscreen reads with
two selected rows. Selected accessibility cells remained exposed and no new
Anki crash report appeared.
This is not yet a distributable Anki fix. Qt 6.11.2 still contains the defect,
and no public PyQt runtime wheel currently contains the candidate. The previous
ID-snapshot experiment is not being proposed because native testing showed it
could hide selected children while leaving the parent deletion intact.
Related identifiers (direct links omitted because this new forum account is not yet permitted to include them):
- OpenAI Codex issue #41374: the same Qt 6.11 accessibilitySelectedChildren route was observed in Qt Creator under SkyComputerUseService.
- Anki Forums topic #38783: an older Anki Browser/VoiceOver report with a different Qt exception.
- Qt regression commit b1ed5f656f064e553b33752f8e87d2f5b9553e38.
- Qt bug QTBUG-149612.
- Qt Gerrit change 765434.
Qt Gerrit patch set 1 has passed Sanity Review and is awaiting human
Code-Review.
Would the maintainers like a GitHub development issue to track the upstream Qt
change and the eventual Anki pyqt6-qt6 runtime update? I will keep any Anki PR
dependency-only and link the confirmed issue. A spoken VoiceOver announcement
check remains pending and will be included in packaged-runtime acceptance.