← back to v146 · stop-re-queueing-launchparams-on-reload
conformance · v146
v146 · stop-re-queueing-launchparams-on-reload — 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 |
|---|---|---|---|---|
launchqueue-exists |
window.launchQueue is exposed (the queue whose reload-time behaviour the change targets). | exists | … | |
launchqueue-setconsumer-function |
launchQueue.setConsumer is the API a PWA uses to receive launches; the new behaviour is observed through this consumer. | typeof | … | |
navigation-type-reload-is-observable |
performance.getEntriesByType('navigation')[0].type lets script distinguish a reload from an original launch — needed to reason about LaunchParams re-queueing. | script | … | |
reload-does-not-redeliver-launchparams |
When the document type is 'reload', the consumer must not be invoked with a fresh non-empty LaunchParams from the original launch — running synchronously after registration, the page sees no replayed targetURL. | script | … | |
launchparams-targeturl-still-defined |
LaunchParams still exposes targetURL — the reload change is about delivery, not about removing the attribute. | script | … | |
navigation-currententry-exposes-url |
navigation.currentEntry.url remains the canonical source of the current document URL after a reload that no longer re-queues LaunchParams. | script | … |