← back to v139 · randomizing-tcp-port-allocation-on-windows
conformance · v139
v139 · randomizing-tcp-port-allocation-on-windows — conformance probe
6 assertions drawn from the spec. Each is a single contract the spec text makes. Pass/fail reflects what this browser executed; blocked means the contract was not run because it needs user mediation, hardware, or another unavailable precondition. Open the page in Chrome stable / canary / Firefox / Safari to compare.
0
pass
0
fail
0
blocked
6
total
| id | contract | kind | verdict | detail |
|---|---|---|---|---|
fetch-still-available |
fetch() is exposed — the random port allocation change is invisible at the JS API surface but TCP-backed APIs must continue to work. | typeof | … | |
websocket-still-available |
WebSocket is still exposed; new TCP connections it opens now use randomized ephemeral ports on Windows. | typeof | … | |
rtc-peerconnection-still-available |
RTCPeerConnection is still exposed. | exists | … | |
user-agent-is-string |
navigator.userAgent is exposed (used to gate Windows-specific behaviour). | typeof | … | |
windows-ua-marker-when-applicable |
If the visitor is on Windows, the UA string still contains a 'Windows' substring (the platform this allocation change targets). | script | … | |
no-port-leak-via-performance-api |
Performance API does not expose remote port numbers (no .remotePort field on PerformanceResourceTiming) — the randomized allocation is not observable to JS by spec. | script | … |