← back to v153 · support-long-animation-frames-api-in-web-workers
conformance · v153
v153 · support-long-animation-frames-api-in-web-workers — 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 |
|---|---|---|---|---|
performance-observer-exists |
The interface the feature is delivered through. spec ↗ | typeof | … | |
main-thread-supports-long-animation-frame |
The baseline this feature extends. Without it on the main thread there is nothing to extend, and the comparison the demos draw would be between two absences. spec ↗ | script | … | |
main-thread-entries-carry-script-attribution |
The field that makes the API worth extending: a blocked frame names the scripts responsible. A duration alone is a metric; a source URL is a bug report. spec ↗ | script | … | |
workers-support-long-animation-frame |
The feature itself: a dedicated worker's PerformanceObserver must list long-animation-frame, so a blocked worker event loop is observable from inside the worker. spec ↗ | script | … | |
a-blocked-worker-is-currently-unobservable-from-the-main-thread |
The blind spot, stated as a contract the demos rely on: a worker busy-looping does not produce a long-animation-frame entry on the main thread, because it is not a main-thread frame. If this ever stopped being true, the blocking demo's central claim would need rewriting. spec ↗ | script | … | |
workers-can-time-their-own-tasks |
The workaround the demos measure against: performance.now is available inside a worker, so a self-rescheduling timer can detect a gap. This is what the feature replaces, and it must keep working for the comparison to mean anything. spec ↗ | script | … |