Let's look the sub-test "Fetch cross-origin no-cors cors-enabled corp-undefined from network and CacheStorage" deeply step by step. The following creates a command for ServiceWorker for loading a cross-origin URL by no-cors mode, and the corp header is undefined. Then sending it to the non-COEP ServiceWorker. https://searchfox.org/mozilla-central/rev/8ccea36c4fb09412609fb738c722830d7098602b/testing/web-platform/tests/html/cross-origin-embedder-policy/require-corp-load-from-cache-storage.https.html#92-107 In the ServiceWorker message event handler, it creates the request by the cross-origin url and no-cors mode. ServiceWorker gets the response by calling fetch(request). Then put the response into the cache v1. https://searchfox.org/mozilla-central/rev/8ccea36c4fb09412609fb738c722830d7098602b/testing/web-platform/tests/html/cross-origin-embedder-policy/resources/sw-store-to-cache-storage.js#9,20,28 Notice that the cached response doesn't have the request_mode information, and it is not supposed to have the request_mode information. Back to require-corp-load-from-cache-storage.https.html. In COEP process, opening the cache v1 and calling catch.match(url) to get the response, and it expects the type of the response is an Error. https://searchfox.org/mozilla-central/rev/8ccea36c4fb09412609fb738c722830d7098602b/testing/web-platform/tests/html/cross-origin-embedder-policy/require-corp-load-from-cache-storage.https.html#110-115 Since the cached response has no request_mode information, it makes no difference between calling with/without setting request mode for the input request of cache.match() in the non-COEP process. They all get the cached response. Since the cache.match() is in COEP process, Applying CORP checking on the cached response. For CORP checking, we need the request_mode. Since the response has no request_mode information, we only can get it from the input request of cache.match(), I think the input request of cache.match is a reasonable source since it is the same with what applied on fetch(). If we send a cors request in fetch() the CORP checking is not supposed to execute, and I assume the same concept on cache.match(). That means if a cors mode request is sent into cache.match(), CORP checking is not supposed to execute. Now we meet the problem when we call cache.match(url_string) since its input request will be cors mode. It makes the CORP checking passed, but we expected it to fail since it is no_cors mode test. Since the test fails, here are some questions. Should the cached response have request_mode information? I guess it should not, otherwise other sub-tests fails since they can not get response. If it should not, why this sub-test expect an error response? Or why not this sub-test calling cache.match() with a no_cors mode request, but an URL string?
Bug 1642531 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Let's look the sub-test "Fetch cross-origin no-cors cors-enabled corp-undefined from network and CacheStorage" deeply step by step. The following creates a command for ServiceWorker for loading a cross-origin URL by no-cors mode, and the corp header is undefined. Then sending it to the non-COEP ServiceWorker. https://searchfox.org/mozilla-central/rev/8ccea36c4fb09412609fb738c722830d7098602b/testing/web-platform/tests/html/cross-origin-embedder-policy/require-corp-load-from-cache-storage.https.html#92-107 In the ServiceWorker message event handler, it creates the request by the cross-origin url and no-cors mode. ServiceWorker gets the response by calling fetch(request). Then put the response into the cache v1. https://searchfox.org/mozilla-central/rev/8ccea36c4fb09412609fb738c722830d7098602b/testing/web-platform/tests/html/cross-origin-embedder-policy/resources/sw-store-to-cache-storage.js#9,20,28 Notice that the cached response doesn't have the request_mode information, and it is not supposed to have the request_mode information. Back to require-corp-load-from-cache-storage.https.html. In COEP process, opening the cache v1 and calling catch.match(url) to get the response, and it expects the type of the response is an Error. https://searchfox.org/mozilla-central/rev/8ccea36c4fb09412609fb738c722830d7098602b/testing/web-platform/tests/html/cross-origin-embedder-policy/require-corp-load-from-cache-storage.https.html#110-115 Since the cached response has no request_mode information, it makes no difference between calling with/without setting request mode for the input request of cache.match() in the non-COEP process. They all get the cached response. Since the cache.match() is in COEP process, Applying CORP checking on the cached response. For CORP checking, we need the request_mode. Since the response has no request_mode information, we only can get it from the input request of cache.match(), I think the input request of cache.match is a reasonable source since it is the same with what applied on fetch(). If we send a cors request in fetch() the CORP checking is supposed to return Allowed, and I assume the same concept on cache.match(). That means if a cors mode request is sent into cache.match(), CORP checking is supposed to return Allowed. Now we meet the problem when we call cache.match(url_string) since its input request will be cors mode. It makes the CORP checking passed, but we expected it to fail since it is no_cors mode test. Since the test fails, here are some questions. Should the cached response have request_mode information? I guess it should not, otherwise other sub-tests fails since they can not get response. If it should not, why this sub-test expect an error response? Or why not this sub-test calling cache.match() with a no_cors mode request, but an URL string?