[Fetch] Disable no-cors in non-serviceworker

[Fetch] Disable no-cors in non-serviceworker

BUG=457157
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=190111

[hiroshige, 2015-02-02 03:20:05]

hiroshige@chromium.org changed reviewers:
+ tyoshino@chromium.org, yhirano@chromium.org

[hiroshige, 2015-02-02 03:20:05]

PTAL.

This is preparation for disabling no-cors in M-42.
After .cpp implementation gets l-g-t-m, I'll add LayoutTests modifications
(splitting out no-cors test cases and marking them FAIL) to this CL.

According to try bots, all failing tests are in fetch-access-control* tests, so
it will be easy to split layout tests.

[yhirano, 2015-02-03 08:06:35]

Don't we need creating a request with 'no-cors' mode to test other functions? In
other words, does this modification decrease the test coverage (other than
disabled feature itself)?

[hiroshige, 2015-02-04 09:34:51]

On 2015/02/03 08:06:35, yhirano wrote:
> Don't we need creating a request with 'no-cors' mode to test other functions?
In
> other words, does this modification decrease the test coverage (other than
> disabled feature itself)?

Good point. I think I have to check when I split failing tests from
fetch-access-control*.
I expect (but am not so sure) functionalities of Request/Response/Headers (i.e.
functionalities of Fetch API that does not involve fetch() calls) are tested
outside fetch-access-control*, and fetch-access-control* are testing Fetch
algorithm (i.e. testing paths that we intend to disable).

[yhirano, 2015-02-05 06:29:18]

On 2015/02/04 09:34:51, hiroshige wrote:
> On 2015/02/03 08:06:35, yhirano wrote:
> > Don't we need creating a request with 'no-cors' mode to test other
functions?
> In
> > other words, does this modification decrease the test coverage (other than
> > disabled feature itself)?
> 
> Good point. I think I have to check when I split failing tests from
> fetch-access-control*.
> I expect (but am not so sure) functionalities of Request/Response/Headers
(i.e.
> functionalities of Fetch API that does not involve fetch() calls) are tested
> outside fetch-access-control*, and fetch-access-control* are testing Fetch
> algorithm (i.e. testing paths that we intend to disable).

Thank you. Please go ahead.

[hiroshige, 2015-02-12 09:48:52]

Patchset #3 (id:40001) has been deleted

[hiroshige, 2015-02-12 09:49:04]

Patchset #3 (id:60001) has been deleted

[hiroshige, 2015-02-12 12:54:30]

1. <Landed> [Fetch] Split layout tests.
https://codereview.chromium.org/921673003/
2. This CL
3. [Fetch] Expose Fetch API to window/workers without flags
https://codereview.chromium.org/913423002/

Now no-cors test cases are already split, this CL is ready.
(The layout test CL was separately commited in 1. above, to confirm that the
split test cases works well when no-cors is not disabled.)
tyoshino@, could you take a look?

[tyoshino (SeeGerritForStatus), 2015-02-13 04:01:00]

lgtm!

[hiroshige, 2015-02-13 04:04:18]

The CQ bit was checked by hiroshige@chromium.org

[commit-bot: I haz the power, 2015-02-13 04:05:14]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/891753002/80001

[tyoshino (SeeGerritForStatus), 2015-02-13 04:11:46]

tyoshino@chromium.org changed reviewers:
+ mkwst@chromium.org

[tyoshino (SeeGerritForStatus), 2015-02-13 04:11:47]

needs owners review
+mkwst

[hiroshige, 2015-02-13 04:15:18]

The CQ bit was unchecked by hiroshige@chromium.org

[Mike West, 2015-02-13 04:54:57]

LGTM.

What is the plan for re-enabling this for document contexts?

[hiroshige, 2015-02-13 05:46:46]

The CQ bit was checked by hiroshige@chromium.org

[commit-bot: I haz the power, 2015-02-13 05:46:58]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/891753002/80001

[commit-bot: I haz the power, 2015-02-13 05:47:34]

Committed patchset #3 (id:80001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=190111

[hiroshige, 2015-03-27 09:13:25]

A revert of this CL (patchset #3 id:80001) has been created in
https://codereview.chromium.org/1041603003/ by hiroshige@chromium.org.

The reason for reverting is: Re-enable no-cors again.
.