I've also confirmed that the same happens for Request.credentials, Request.cache, and Request.redirect. When you initialize a request object with invalid values (values not appearing in the enums provided in the spec i.e. https://fetch.spec.whatwg.org/#requestcredentials) no TypeError is thrown, though the default value is still used anyways. Firefox and Safari both throw in these cases.

I was wondering if the right way to go about fixing this would be to have `SetUpMode`, `SetUpCredentials`, `SetUpCache`, and `SetUpRedirect` methods in RequestInit.cpp similar to `SetUpReferrer` that are responsible for switching on the provided Dictionary values, and either setting the respective `mode_`, `credentials_`, `cache_`, and `redirect_` values, or throwing? It would be similar to: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/fetch/RequestInit.cpp?q=RequestInit.cpp&sq=package:chromium&l=163.

If this sounds good, I can go ahead an implement.

Able to reproduce the issue on Windows 7,Mac 10.12.6 & Ubuntu 14.04 using chrome reported version-61.0.3163.100, stable-62.0.3202.62 & canary-64.0.3250.0 as per below steps:

1. Launch chrome & go to NTP
2. Open dev tools (Press F12)
3. Go to 'Console'
4. paste code as below 
  x = new Request("", {mode: "whatever"})
5. No error displayed

Same issue observed from M50 builds to latest chrome versions. As it is a non regression issue, marking it as Untriaged for further investigation.

Please find the attached screencast for reference.

Thanks..!



	

Deleted: 777116.mp4 1.2 MB

	777116.mp4 1.2 MB View Download

Thanks for reporting, this is a bug in Fetch API. Usually such issues are handled in the IDL parser but in this case we are doing the work manually, and we should have these checks in it.

The logic is located in modules/fetch/RequestInit.cpp[1]. You can throw a TypeError by calling exception_state.ThrowTypeError(message) and return from RequestInit::RequestInit.

1: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/fetch/RequestInit.cpp

Thanks a lot, I'll start checking it out and submit a patch soon! Is there any particular reason we're not handling this with the IDL parser, and instead are checking for this manually?

Also this question may be out of the scope of this issue, but is there a way I can compile to get debugging symbols included on files in the WebKit folder? I was trying to debug some of the fetch code with gdb, and it seemed that no symbols could be found for any of the source files in there with the `ninja -C out/Default chrome`?. Is there something I can do to debug code in this directory? Perhaps a way to include symbols here?

> #5

I don't fully understand the reason, but the bindings team said the current Dictionary implementation in the IDL parser had some problems.

> #6

Having "is_debug=true" in GN settings will produce binaries with debug information.

https://chromium.googlesource.com/chromium/src/+/master/docs/linux_build_instructions.md

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b66d10ef54411e51c74d8b816162bd8a149ed2eb

commit b66d10ef54411e51c74d8b816162bd8a149ed2eb
Author: Dominic Farolino <domfarolino@gmail.com>
Date: Wed Mar 07 18:42:27 2018

Enforce RequestInit enum values

This makes the Fetch API more standards compliant by
enforcing the enum values in the RequestInit dictionary,
as this is not taken care of by the IDL bindings themselves.
This enforces the mode, credentials, cache, and redirect properties
of RequestInit.

R=yhirano@chromium.org, yoav@yoav.ws

Bug:  777116 
Change-Id: I8db5fd991b5ffa039dc2f67b4d8f525647fbf915
Reviewed-on: https://chromium-review.googlesource.com/841270
Commit-Queue: Yoav Weiss <yoav@yoav.ws>
Reviewed-by: Yoav Weiss <yoav@yoav.ws>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#541515}
[modify] https://crrev.com/b66d10ef54411e51c74d8b816162bd8a149ed2eb/third_party/WebKit/LayoutTests/external/wpt/fetch/api/request/request-error-expected.txt
[modify] https://crrev.com/b66d10ef54411e51c74d8b816162bd8a149ed2eb/third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/webvtt-cross-origin.https.html
[modify] https://crrev.com/b66d10ef54411e51c74d8b816162bd8a149ed2eb/third_party/WebKit/LayoutTests/http/tests/fetch/script-tests/request.js
[modify] https://crrev.com/b66d10ef54411e51c74d8b816162bd8a149ed2eb/third_party/WebKit/Source/core/fetch/RequestInit.cpp
[modify] https://crrev.com/b66d10ef54411e51c74d8b816162bd8a149ed2eb/third_party/WebKit/Source/core/fetch/RequestInit.h
[modify] https://crrev.com/b66d10ef54411e51c74d8b816162bd8a149ed2eb/third_party/WebKit/Source/platform/weborigin/ReferrerPolicy.h

Looks like this can be closed?

Yes, not sure how this is done or if I have the permissions to do so, but it can be closed. Thanks.