"no-cors" mode is used, for example, when a page has an <img> tag with src="http://someotherOrigin.com" where the image is displayed, or canvas where you may set the bitmap to another origin but then may no longer access the data. If a service-worker returns an opaque Response it must have been in response to a Request with mode "no-cors". Implement Section 4.2 step 2.2 - https://fetch.spec.whatwg.org/#http-fetch 1) In dom/fetch/ServiceWorkerEvents.cpp, in the ResolvedCallback(), after unwrapping the Response check that if the initiating Request (the implementer will have to add some way to get at the FetchEvent's Request, or just track what the Request's mode was) has mode no-cors and Response's Type() is not opaque, to just return. 2) Write a test case using mochitest in dom/workers/test/serviceworkers/fetch/fetch_tests.js to add a call to fetch("crossOriginURL", { mode: "no-cors" }). There are a couple of tests. a) no-cors request, sw returns opaque response -> pass b) "same-origin" request, sw returns opaque response -> error

/r/5547 - Bug 1136200 - Verify request type is not no-cors if response is opaque Pull down this commit: hg pull review -r 17ea7e7061bf0814a0b3f13fc8b94b3679545af8

Comment on attachment 8578876 [details] MozReview Request: bz://1136200/nsm https://reviewboard.mozilla.org/r/5545/#review4551 ::: dom/workers/ServiceWorkerEvents.cpp (Diff revision 1) > return; This isn't a network error, is it? Doesn't this make the original request go through unintercepted?

Comment on attachment 8578876 [details] MozReview Request: bz://1136200/nsm https://reviewboard.mozilla.org/r/5545/#review4683 Ship It!