# Browser Compatibility Matrix
This document describes current browser support expectations for jsmpi runtime behavior.
## Scope
- Browser execution model: Coordinator + Web Workers + WASM module loading.
- Synchronization model: SharedArrayBuffer + Atomics for blocking receive/barrier.
- Compatibility target: recent stable versions of major browsers.
## Capability Matrix
| Web Worker (module worker) | ✅ | ✅ | ✅ | ✅ |
| WebAssembly module loading | ✅ | ✅ | ✅ | ✅ |
| SharedArrayBuffer (cross-origin isolated) | ✅ | ✅ | ✅ | ✅ (version and policy dependent) |
| Atomics.wait in worker | ✅ | ✅ | ✅ | ✅ (version dependent) |
| Blocking recv/barrier path | ✅ | ✅ | ✅ | ⚠️ Requires strict COOP/COEP and compatible Safari version |
## Required Headers
For reliable blocking semantics with SharedArrayBuffer:
- `Cross-Origin-Opener-Policy: same-origin`
- `Cross-Origin-Embedder-Policy: require-corp`
Without these headers, runtime falls back to non-blocking behavior and logs `CAPABILITY_MISSING_SAB`.
## Behavior Differences
- Chrome/Edge: generally the most stable baseline for current e2e validation.
- Firefox: supported, but verify worker scheduling behavior under high rank counts.
- Safari: verify both version and deployment headers; missing isolation often disables SAB.
## Validation Recommendation
Run at least:
1. `npm run build:demo`
2. `npm run test:browser:e2e`
3. Manual demo smoke test on each target browser with `hello_ranks`, `ping_pong`, `sum_reduction`.
## Known Risks
- If deployment headers are incomplete, blocking operations degrade and timing metrics are less representative.
- Browser scheduler differences may increase barrier wait variance at larger rank counts.