Bugzilla

Thanks for explaining, but I am still confused.

https://w3c.github.io/ServiceWorker/#request-matches-cached-item only mentioned the input of cache.match is a request. But it doesn't mention if the mode is taken into account. In fact, the input request could have a specific mode.

if the input is a string, new Request(input) is called implicitly, and cors mode is set in default.

If we don't take the input request's mode into account, that means https://wicg.github.io/cross-origin-embedder-policy/#corp-check step 1 would not be executed when cache.match()/cache.matchAll() is called. And it also could make a TypeError for the following code. 

try {
  const request = new Request(url, {mode: "cors"});
  let responst = cache.match(request);
} catch(e) {
  // got an TypeError, since CORP checking failed.  
}

And I am not sure should this TypeError be expected. And the following sub-tests fail in CORP checking if we ignore the input request's mode.
Fetch cross-origin cors from service-worker and CacheStorage. 
Fetch cross-origin no-cors from service-worker and CacheStorage
Fetch same-origin cors from service-worker and CacheStorage
Fetch same-origin no-cors from service-worker and CacheStorage
Fetch cross-origin cors cors-enabled corp-undefined from network and CacheStorage
Fetch same-origin no-cors cors-disabled corp-undefined from network and CacheStorage
Fetch same-origin no-cors cors-enabled corp-undefined from network and CacheStorage
Fetch cross-origin cors cors-enabled corp-undefined from network and CacheStorage

Thanks for explaining, but I am still confused.

https://w3c.github.io/ServiceWorker/#request-matches-cached-item only mentioned the input of cache.match is a request. But it doesn't mention if the mode is taken into account. In fact, the input request could have a specific mode.

if the input is a string, new Request(input) is called implicitly, and cors mode is set in default.

The problem is we need to apply CORP checking on the response of cache.match(). If we don't take the input request's mode into account, that means https://wicg.github.io/cross-origin-embedder-policy/#corp-check step 1 would not be executed when cache.match()/cache.matchAll() is called. And it also could make a TypeError for the following code. 

try {
  const request = new Request(url, {mode: "cors"});
  let responst = cache.match(request);
} catch(e) {
  // got an TypeError, since CORP checking failed.  
}

And I am not sure should this TypeError be expected. And the following sub-tests fail in CORP checking if we ignore the input request's mode.
Fetch cross-origin cors from service-worker and CacheStorage. 
Fetch cross-origin no-cors from service-worker and CacheStorage
Fetch same-origin cors from service-worker and CacheStorage
Fetch same-origin no-cors from service-worker and CacheStorage
Fetch cross-origin cors cors-enabled corp-undefined from network and CacheStorage
Fetch same-origin no-cors cors-disabled corp-undefined from network and CacheStorage
Fetch same-origin no-cors cors-enabled corp-undefined from network and CacheStorage
Fetch cross-origin cors cors-enabled corp-undefined from network and CacheStorage

Thanks for explaining, but I am still confused.

https://w3c.github.io/ServiceWorker/#request-matches-cached-item only mentioned the input of cache.match is a request. But it doesn't mention if the mode is taken into account. In fact, the input request could have a specific mode.

if the input is a string, new Request(input) is called implicitly, and cors mode is set in default.

The problem is we need to apply CORP checking on the response of cache.match(). If we don't take the input request's mode into account, that means https://wicg.github.io/cross-origin-embedder-policy/#corp-check step 1 would not be executed when cache.match()/cache.matchAll() is called. And it also could make a TypeError for the following code. 

try {
  const request = new Request(url, {mode: "cors"});
  let responst = cache.match(request);
} catch(e) {
  // got an TypeError, since CORP checking failed.  
}

And I am not sure should this TypeError be expected. And the following sub-tests fail in CORP checking if we ignore the input request's mode.
Fetch cross-origin cors from service-worker and CacheStorage. 
Fetch same-origin cors from service-worker and CacheStorage
Fetch cross-origin cors cors-enabled corp-undefined from network and CacheStorage
Fetch cross-origin cors cors-enabled corp-undefined from network and CacheStorage

Thanks for explaining, but I am still confused.

https://w3c.github.io/ServiceWorker/#request-matches-cached-item only mentioned the input of cache.match is a request. But it doesn't mention if the mode is taken into account. In fact, the input request could have a specific mode.

if the input is a string, new Request(input) is called implicitly, and cors mode is set in default.

The problem is we need to apply CORP checking on the response of cache.match(). If we don't take the input request's mode into account, that means https://wicg.github.io/cross-origin-embedder-policy/#corp-check step 1 would not be executed when cache.match()/cache.matchAll() is called. And it also could make a TypeError for the following code. 

try {
  const request = new Request(url, {mode: "cors"});
  let responst = cache.match(request);
} catch(e) {
  // got an TypeError, since CORP checking failed.  
}

And I am not sure should this TypeError be expected.

And the following sub-tests fail in CORP checking if we ignore the input request's mode.
Fetch cross-origin cors from service-worker and CacheStorage. 
Fetch same-origin cors from service-worker and CacheStorage
Fetch cross-origin cors cors-enabled corp-undefined from network and CacheStorage
Fetch cross-origin cors cors-enabled corp-undefined from network and CacheStorage

These fail tests make no sense to me since it specifies the mode is cors, and according to CORP checking spec, it should be allowed.

Thanks for explaining, but I am still confused.

https://w3c.github.io/ServiceWorker/#request-matches-cached-item only mentioned the input of cache.match is a request. But it doesn't mention if the mode is taken into account. In fact, the input request could have a specific mode.

if the input is a string, new Request(input) is called implicitly, and cors mode is set in default.

The problem is we need to apply CORP checking on the response of cache.match(). If we don't take the input request's mode into account, that means https://wicg.github.io/cross-origin-embedder-policy/#corp-check step 1 would not be executed when cache.match()/cache.matchAll() is called. And it also could make a TypeError for the following code. 

try {
  const request = new Request(url, {mode: "cors"});
  let responst = cache.match(request);
} catch(e) {
  // got an TypeError, since CORP checking failed.  
}

And I am not sure if this TypeError is expected.

And the following sub-tests fail in CORP checking if we ignore the input request's mode.
Fetch cross-origin cors from service-worker and CacheStorage. 
Fetch same-origin cors from service-worker and CacheStorage
Fetch cross-origin cors cors-enabled corp-undefined from network and CacheStorage
Fetch cross-origin cors cors-enabled corp-undefined from network and CacheStorage

These fail tests make no sense to me since it specifies the mode is cors, and according to CORP checking spec, it should be allowed.

Thanks for explaining, but I am still confused.

https://w3c.github.io/ServiceWorker/#request-matches-cached-item only mentioned the input of cache.match is a request. But it doesn't mention if the mode is taken into account. In fact, the input request could have a specific mode.

if the input is a string, new Request(input) is called implicitly, and cors mode is set in default.

The problem is we need to apply CORP checking on the response of cache.match(). If we don't take the input request's mode into account, that means https://wicg.github.io/cross-origin-embedder-policy/#corp-check step 1 would not be executed when cache.match()/cache.matchAll() is called. And it also could make a TypeError for the following code. 

try {
  const request = new Request(url, {mode: "cors"});
  let responst = cache.match(request);
} catch(e) {
  // got an TypeError, since CORP checking failed.  
}

And I am not sure if this TypeError is expected.

And the following sub-tests fail in CORP checking if we ignore the input request's mode.
Fetch cross-origin cors from service-worker and CacheStorage. 
Fetch same-origin cors from service-worker and CacheStorage
Fetch cross-origin cors cors-enabled corp-undefined from network and CacheStorage
Fetch cross-origin cors cors-enabled corp-undefined from network and CacheStorage

These fail tests make no sense to me since it specifies the mode is cors, and according to CORP checking spec, the checking should be skipped.

Thanks for explaining, but I am still confused.

https://w3c.github.io/ServiceWorker/#request-matches-cached-item only mentioned the input of cache.match is a request. But it doesn't mention if the mode is taken into account. In fact, the input request could have a specific mode.

if the input is a string, new Request(input) is called implicitly, and cors mode is set in default.

The problem is we need to apply CORP checking on the response of cache.match(). If we don't take the input request's mode into account, that means https://wicg.github.io/cross-origin-embedder-policy/#corp-check step 1 would be ignored when cache.match()/cache.matchAll() is called. And it also could make a TypeError for the following code. 

try {
  const request = new Request(url, {mode: "cors"});
  let responst = cache.match(request);
} catch(e) {
  // got an TypeError, since CORP checking failed.  
}

And I am not sure if this TypeError is expected.

And the following sub-tests fail in CORP checking if we ignore the input request's mode.
Fetch cross-origin cors from service-worker and CacheStorage. 
Fetch same-origin cors from service-worker and CacheStorage
Fetch cross-origin cors cors-enabled corp-undefined from network and CacheStorage
Fetch cross-origin cors cors-enabled corp-undefined from network and CacheStorage

These fail tests make no sense to me since it specifies the mode is cors, and according to CORP checking spec, the checking should be skipped.

Thanks for explaining, but I am still confused.

https://w3c.github.io/ServiceWorker/#request-matches-cached-item only mentioned the input of cache.match is a request. But it doesn't mention if the mode is taken into account. In fact, the input request could have a specific mode.

If the input is a string, new Request(input) is called implicitly, and cors mode is set in default.

The problem is we need to apply CORP checking on the response of cache.match(). If we don't take the input request's mode into account, that means https://wicg.github.io/cross-origin-embedder-policy/#corp-check step 1 would be ignored when cache.match()/cache.matchAll() is called. And it also could make a TypeError for the following code. 

try {
  const request = new Request(url, {mode: "cors"});
  let responst = cache.match(request);
} catch(e) {
  // got an TypeError, since CORP checking failed.  
}

And I am not sure if this TypeError is expected.

And the following sub-tests fail in CORP checking if we ignore the input request's mode.
Fetch cross-origin cors from service-worker and CacheStorage. 
Fetch same-origin cors from service-worker and CacheStorage
Fetch cross-origin cors cors-enabled corp-undefined from network and CacheStorage
Fetch cross-origin cors cors-enabled corp-undefined from network and CacheStorage

These fail tests make no sense to me since it specifies the mode is cors, and according to CORP checking spec, the checking should be skipped by step 1.