1643611 - Stop intercepting requests in embed and object elements

Status: RESOLVED FIXED

(Core :: DOM: Service Workers, defect, P2)

Description

[Anne (:annevk)]

As per WPT service-workers/service-worker/embed-and-object-are-not-intercepted.https.html and https://github.com/w3c/ServiceWorker/pull/1486 no navigations inside embed and object elements should be intercepted.

This came up as part of https://github.com/whatwg/fetch/pull/948.

Comment 1

[Anne (:annevk)]

Fixing this might be important for ORB as otherwise we route requests through the service worker that will get blocked by ORB whereas they would not if they were not intercepted at all. I'm not sure how many sites use embed/object and have a service worker as well, but if any exist we shouldn't impact them.

Comment 2

[Jens Stutte [:jstutte]]

Hi Andrew, could you please help us with understanding the effort needed here?

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

So this might be a good thing for :jmarshall to look at as a more atomic fix.

The general situation is this:

• Spec:
  • The HTTP fetch algorithm in the fetch spec in step 5.4 calls the Handle Fetch algorithm in the SW spec where step 14 is "If request’s destination is either "embed" or "object", then: Return null." This change happened in https://github.com/w3c/ServiceWorker/pull/1486 and we haven't updated to handle this.
  • The destination exists as RequestDestination.
• Our implementation:
  • Because necko's internal concept of destinations pre-dates fetch's concept of destinations, we have our own internal nsIContentPolicy enum type that gets mapped to RequestDestination types by mozilla::dom::InternalRequest::MapContentPolicyTypeToRequestDestination. For example, currently TYPE_OBJECT and TYPE_INTERNAL_OBJECT both map to RequestDestination::Object.
  • There's somewhat of a 2-layer check for deciding whether to intercept something:
    • mozilla::net::HttpBaseChannel::ShouldIntercept first makes sure the request is eligible for redirection.
    • mozilla::dom::ServiceWorkerInterceptController::ShouldPrepareForIntercept Is where the ServiceWorker logic gets involved and applies storage access rules (if you can't access storage for a principal, you can't see the ServiceWorkers!) as well as checks whether there are any matching scopes for navigations, or just asks the existing ServiceWorker (controller) if it's not a navigation. (Where navigation is oddly defined as "not being a subresource load" and involving delightful double-negations because of that.)
      • Note that the first big block of code in the method deals with subresources, and then the rest is considering navigations (non-subresource requests). Also note that it's step 15 and step 16 of handle fetch that are where they start to care about navigation versus sub-resource, but the new destination check is in step 14, so our destination check would want to go near the top of the method-ish.

With a check added, we expect the test https://searchfox.org/mozilla-central/source/testing/web-platform/tests/service-workers/service-worker/embed-and-object-are-not-intercepted.https.html to start passing which means that the disablings in the corresponding meta file at https://searchfox.org/mozilla-central/source/testing/web-platform/meta/service-workers/service-worker/embed-and-object-are-not-intercepted.https.html.ini would be removed... possibly removing the whole file.

Comment 4

[Hsin-Yi Tsai (she/her) [:hsinyi]]

hi Andrew/Marshall,
Any updates here? Thank you. :)

Comment 5

[Joshua Marshall]

Attachment: Bug 1643611 - Stop intercepting requests in embed and object elements r=edenchuang

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b7af43abc684
Stop intercepting requests in embed and object elements r=edenchuang

Comment 7

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/b7af43abc684