Please refer to bug 1222008 comment #55. Basically, when the service worker intercepts a "same-origin" mode request and responds a "Cors" type response, we would like to reject the promise. However, we need to deal with this case after collecting data in bug 1416629. Thus, the temporary solution for this is to have a pref which have a method to trim the response and turn it on by default. The method to trim the response should behave the same as the following js executed in the service worker's script: var quirkResponse = new Response(corsResponse.body, corsResponse);

It should be a follow-up patch instead of a follow-up bug

Reopen the bug since we decide to reject the promise by default and add a pref for enabling the quirk response.

Ha! I forgot you wrote this bug and I asked you to close it before. So sorry for the back and forth.

Tom, given the low hit rate on the telemetry in both Firefox and chrome so far, let's wait to put any more effort in here for a while. We can check the telemetry again in January and add the quick before 59 merged to beta then, if necessary. Sound reasonable?

(In reply to Ben Kelly [:bkelly] from comment #5) > Tom, given the low hit rate on the telemetry in both Firefox and chrome so > far, let's wait to put any more effort in here for a while. We can check > the telemetry again in January and add the quick before 59 merged to beta > then, if necessary. > > Sound reasonable? Yeah, sounds reasonable. Thanks!

From 2017/11/24 to 2018/01/02, we get around 340k service worker's synthesized responses[1] from our telemetry while none of them is made of cors response for the same-origin request[2]. Meanwhile, I cannot find any result by searching "RespondToSameOriginRequestWithCrossOriginResponse" from Chrome's usage statistics[3]. Perhaps, we could close this bug for now? [1] https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-01-02&keys=__none__!__none__!__none__&max_channel_version=nightly%252F59&measure=SCALARS_SW.SYNTHESIZED_RES_COUNT&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-11-24&table=0&trim=1&use_submission_date=0 [2] https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-01-02&keys=__none__!__none__!__none__!__none__&max_channel_version=nightly%252F59&measure=SCALARS_SW.CORS_RES_FOR_SO_REQ_COUNT&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-11-24&table=0&trim=1&use_submission_date=0 [3] https://www.chromestatus.com/metrics/feature/popularity

Sounds reasonable. Can you look at updating the tests we marked expected fail for this change? We should also signal to the spec we want to ship this.

(In reply to Ben Kelly [:bkelly] from comment #8) > Sounds reasonable. Can you look at updating the tests we marked expected > fail for this change? We should also signal to the spec we want to ship > this. Sure, I filed bug 1427978 for it.

Mark this bug as "won't fix" based on the result of collecting data in comment #7