Skip to content

fix(track,config,ui): harden the Java Access Bridge: SEH containment, step logs, UIPI race, trackJava (#515) - #518

Merged
Maxaubert merged 2 commits into
mainfrom
fix/java-bridge-hardening-515
Oct 26, 2026
Merged

Maxaubert merged 2 commits into
mainfrom
fix/java-bridge-hardening-515

Conversation

@Maxaubert

Copy link
Copy Markdown
Owner

Closes #515. Field report: Wind crashed entering a Java app with NVDA running (NVDA keeps the bridge live in every JVM, so the full bridge path runs inside Wind).

  • Every bridge DLL call and Wind's callbacks go through SEH-only thunks; a fault logs code/address/module, marks the bridge broken for the session and retires its windows. LoadLibraryExW is deliberately not guarded (loader lock).
  • Flushed step logs: DLL path + file version, load, message filter, Windows_run, callbacks, first event, Java process path/bitness.
  • UIPI race: bridge messages allowed process-wide just before Windows_run, then per window, then the process-wide allowance removed.
  • New trackJava setting (default 1, profile key): 0 never loads the bridge. Settings row 'Follow text in Java apps' under caret tracking.
  • Pure helpers + doctest; 07-cursor.md, 08-config-profiles.md updated.

Verification: build.bat, check, test 671/671, Playwright 212/212, test:rules pass. Deployed signed UIAccess build: a Swing test app on JDK 21 loaded the bridge (v21.0.12), 7/7 process-wide + 14 per-window allowances, first caret event received, no crash. Not tested with NVDA running.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BjTV6Wj6XLqULZWUmqiVYJ

Maxaubert and others added 2 commits October 26, 2026 09:11
… step logs, UIPI race, trackJava (#515)

- Every call into the bridge DLL (Windows_run, set*FP, isJavaWindow,
  getAccessibleContextWithFocus, getAccessibleTextInfo, getCaretLocation,
  getAccessibleTextRect, releaseJavaObject), Wind's callback bodies and the
  tracker's DispatchMessageW go through SEH-only thunks. A fault logs code,
  address and module, marks the bridge broken for the session (callbacks
  become no-ops, never called or reloaded) and retires its windows.
  LoadLibraryExW stays unguarded on purpose (loader lock).
- Flushed step logs: DLL path and file version, before/after the load, the
  message filter, Windows_run, callback registration, the first event, and
  each Java process's path and bitness on first contact.
- UIPI: the bridge messages are allowed process-wide just before
  Windows_run (a live JVM, as with NVDA, answers at once), then per window
  on the windows it created, and the process-wide allowance is removed.
- New setting trackJava (default 1, "Follow text in Java apps"): 0 never
  loads the bridge DLL. Config, template, parser, schema, fixture, docs.
- Pure helpers FormatFileVersion and kJabFixedMessages with doctest cover.

Closes #515

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BjTV6Wj6XLqULZWUmqiVYJ
…ack in its bullet

The first-contact JVM path/bitness line is now flushed like the setup steps (the docs
already said so), and the MSAA caret sentence moves back to the caret-sources bullet it
was split from.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BjTV6Wj6XLqULZWUmqiVYJ
@Maxaubert
Maxaubert merged commit e764d40 into main Oct 26, 2026
1 check passed
@Maxaubert
Maxaubert deleted the fix/java-bridge-hardening-515 branch October 26, 2026 08:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Wind crashes when entering a Java app with NVDA running

1 participant