Introduce "navigate" mode in Requests

third_party/WebKit/Source/modules/fetch/RequestInit.cpp

Index: third_party/WebKit/Source/modules/fetch/RequestInit.cpp
diff --git a/third_party/WebKit/Source/modules/fetch/RequestInit.cpp b/third_party/WebKit/Source/modules/fetch/RequestInit.cpp
index a13e08209986fc0a8c978713f9a42086457d5878..4b82e7b6f79cd84452d7c3bc37378ba6a64c54d8 100644
--- a/third_party/WebKit/Source/modules/fetch/RequestInit.cpp
+++ b/third_party/WebKit/Source/modules/fetch/RequestInit.cpp
@@ -23,10 +23,8 @@
 namespace blink {
 
 RequestInit::RequestInit(ExecutionContext* context, const Dictionary& options, ExceptionState& exceptionState)
-    : opaque(false), isReferrerSet(false)
+    : opaque(false), areAnyMembersSet(false)
 {
-    bool areAnyMembersSet = false;
-
     areAnyMembersSet = DictionaryHelper::get(options, "method", method) || areAnyMembersSet;

[Mike West, 2015/10/20 07:27:04]

Nit: here and elsewhere, `|=` would be clearer.

[shiva.jm, 2015/10/21 08:34:59]

only at these line(30), it holds good,
but for other lines, it might fail for cases
where more than 1 member is set, i.e 
if 'method' also true != 'headers' also true.
so we can only apply `|=` at line 30 only.

[hiroshige, 2015/10/30 12:31:30]

Anyway, if we want to do that change, I think it is better to do it in a
separate CL, so my comment below doesn't block this CL.

How it fails when both |method| and |headers| are set?

These two alternatives have pros and cons.
I slightly prefer 2. as mkwst@ suggested.

1. areAnyMembersSet = get() || areAnyMembersSet
get() is on the left-hand side to avoid short-circuit of || operator.
I.e. "areAnyMembersSet = areAnyMembersSet || get(options, "headers", headers)"
is a bug, because get() is not called and thus headers field is not set if
areAnyMembersSet is true.
This is somehow error-prone.

2. areAnyMembersSet |= get()
'|=' is bitwise OR (not ||) and thus does not short-circuit.
So get() is always called, avoiding the problem of 1.

A possible drawback is that we use logical computation using bitwise operators
-- reminds us of the ghost of the problem that (1 && 2) is true but (1 & 2) is
false.
In this case, it seems OK:
- areAnyMembersSet is bool, and bool has only 0 or 1.
- This is OR operator, so both (1 || 2) and (1 | 2) are true.

3. or should we write like the following?
if (get())
    areAnyMembersSet = true;

[shiva.jm, 2015/11/02 12:06:20]

Thanks for more detailed inputs, i misunderstand the
bitwise '|=' operator operation. agree with option 2 above,
so we can change as below:

1) areAnyMembersSet = DictionaryHelper::get() || areAnyMembersSet;
----> areAnyMembersSet |= get();
2) areAnyMembersSet = areAnyMembersSet || isReferrerStringSet;
----> areAnyMembersSet |= isReferrerStringSet;
3) areAnyMembersSet = areAnyMembersSet || isBodySet;
----> areAnyMembersSet |= isBodySet;

shall we change in these CL Or separate CL?

     areAnyMembersSet = DictionaryHelper::get(options, "headers", headers) || areAnyMembersSet;
     if (!headers) {
@@ -61,7 +59,6 @@ RequestInit::RequestInit(ExecutionContext* context, const Dictionary& options, E
         referrer = Referrer("about:client", ReferrerPolicyDefault);
         if (isReferrerStringSet)
             referrer.referrer = referrerString;
-        isReferrerSet = true;
     }
 
     if (!isBodySet || v8Body->IsUndefined() || v8Body->IsNull())