- From: Yoshisato Yanagisawa <notifications@github.com>
- Date: Fri, 29 Aug 2025 04:59:53 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Friday, 29 August 2025 11:59:57 UTC
yoshisatoyanagisawa left a comment (w3c/ServiceWorker#249) You're right to ask why this is different from an `<iframe>`. The key challenge is that `<object>` and `<embed>` don't always create a new browsing context; it depends entirely on the response's MIME type, which is unknown when the request is made (which is what I have understood from the discussion). An `<iframe>` is always a navigation request for a new context. In contrast, `<object>` and `<embed>` create an ambiguity: should the Service Worker treat the request as a simple subresource fetch for the current page, or as a navigation that should be handled by the new context's own Service Worker? Resolving this ambiguity after the response has been received would require complex mechanisms, like restarting the request entirely. Given the significant implementation cost for what are now niche use cases, it has been difficult to justify prioritizing a complete solution. Therefore, I support maintaining the current behavior of not intercepting these requests. It strikes the right balance between platform completeness and the practical cost of implementation. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/issues/249#issuecomment-3236791796 You are receiving this because you are subscribed to this thread. Message ID: <w3c/ServiceWorker/issues/249/3236791796@github.com>
Received on Friday, 29 August 2025 11:59:57 UTC