Navigation preload shouldn't occur when there is no fetch event handler

[mfalken]

As written, the spec sends a navigation preload (#920) request even if there is no fetch event handler.

But this seems meaningless. The SW can't use the preload response. And the "real" navigation request will be sent immediately after the preload request since SW startup doesn't happen.

We could possibly reject the enable() promise in this case, or at least browsers should emit a developer warning.

Chrome 57's implementation does not send the preload, but it doesn't yet warn or reject on enable(), which could be confusing.

WDYT? @jakearchibald @n8schloss @wanderview

[jakearchibald]

Good catch. The preload fetch shouldn't be sent if there's no fetch listener.

I don't think enable() should reject in this case, as preloading is a property of the registration, but "having a fetch listener" is a property of the service worker. Eg, I could successfully enable(), then update to a service worker without a fetch handler.

[mfalken]

I don't think enable() should reject in this case, as preloading is a property of the registration, but "having a fetch listener" is a property of the service worker. Eg, I could successfully enable(), then update to a service worker without a fetch handler.

Makes sense.