Use ExecutionContext instead of Document in PaymentRequest constructor.

Use ExecutionContext instead of Document in PaymentRequest constructor.

BUG=683329
Review-Url: https://codereview.chromium.org/2697123003
Cr-Commit-Position: refs/heads/master@{#452494}
Committed: https://chromium.googlesource.com/chromium/src/+/a4cf0dc85a9d52d8d1a07ee15ae7bd0c8bc02b06

[please use gerrit instead, 2017-02-16 16:03:38]

Description was changed from

==========
Use ScriptState instead of Document in PaymentRequest

BUG=683329
==========

to

==========
Use ScriptState instead of Document in PaymentRequest

Because PaymentRequest object inherits from ContextObserver, it always
has access to the current execution context, frame, and script state.
Therefore, it's not necessary to pass ScriptState into every function.

In addition, passing Document into the constructor edges on dangerous,
because storing an instance of Document is prohibited, but it's easy to
make that mistake when the constructor takes a Document. Therefore, this
patch accepts a ScriptState in the constructor instead of a Document.

BUG=683329
==========

[please use gerrit instead, 2017-02-16 16:04:36]

Description was changed from

==========
Use ScriptState instead of Document in PaymentRequest

Because PaymentRequest object inherits from ContextObserver, it always
has access to the current execution context, frame, and script state.
Therefore, it's not necessary to pass ScriptState into every function.

In addition, passing Document into the constructor edges on dangerous,
because storing an instance of Document is prohibited, but it's easy to
make that mistake when the constructor takes a Document. Therefore, this
patch accepts a ScriptState in the constructor instead of a Document.

BUG=683329
==========

to

==========
Use ScriptState instead of Document in PaymentRequest

Because PaymentRequest object inherits from ContextObserver, it always
has access to the current execution context, frame, and script state.
Therefore, it's not necessary to pass ScriptState into every function.

In addition, passing Document into the constructor edges on dangerous,
because storing an instance of Document is prohibited, but it's easy to
make that mistake when the constructor takes a Document. Therefore, this
patch accepts a ScriptState in the constructor instead of a Document.

The resulting patch reduces the number of lines of code by 28.

BUG=683329
==========

[please use gerrit instead, 2017-02-16 16:04:41]

The CQ bit was checked by rouslan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-16 16:05:14]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[please use gerrit instead, 2017-02-16 16:07:51]

Description was changed from

==========
Use ScriptState instead of Document in PaymentRequest

Because PaymentRequest object inherits from ContextObserver, it always
has access to the current execution context, frame, and script state.
Therefore, it's not necessary to pass ScriptState into every function.

In addition, passing Document into the constructor edges on dangerous,
because storing an instance of Document is prohibited, but it's easy to
make that mistake when the constructor takes a Document. Therefore, this
patch accepts a ScriptState in the constructor instead of a Document.

The resulting patch reduces the number of lines of code by 28.

BUG=683329
==========

to

==========
Use ScriptState instead of Document in PaymentRequest

Because PaymentRequest object inherits from ContextObserver, it always
has access to the current execution context, frame, and script state.
Therefore, it's not necessary to pass ScriptState into every function.

In addition, this patch accepts a ScriptState instead
of a Document in the constructor of PaymentRequest.

The resulting patch reduces the number of lines of code by 28.

BUG=683329
==========

[please use gerrit instead, 2017-02-16 16:10:28]

Description was changed from

==========
Use ScriptState instead of Document in PaymentRequest

Because PaymentRequest object inherits from ContextObserver, it always
has access to the current execution context, frame, and script state.
Therefore, it's not necessary to pass ScriptState into every function.

In addition, this patch accepts a ScriptState instead
of a Document in the constructor of PaymentRequest.

The resulting patch reduces the number of lines of code by 28.

BUG=683329
==========

to

==========
Use ScriptState instead of Document in PaymentRequest

Because PaymentRequest is a ContextLifecycleObserver, it always has
access to the current execution context, frame, and script state.
Therefore, it's not necessary to pass ScriptState into every function.

In addition, this patch accepts a ScriptState instead
of a Document in the constructor of PaymentRequest.

The resulting patch reduces the number of lines of code by 28.

BUG=683329
==========

[please use gerrit instead, 2017-02-16 16:15:47]

rouslan@chromium.org changed reviewers:
+ mek@chromium.org

[please use gerrit instead, 2017-02-16 16:15:47]

Marijn, ptal. This is split from http://crrev.com/2645813006, which is getting
giant, so I want to make it a bit smaller.

[commit-bot: I haz the power, 2017-02-16 17:25:45]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-16 17:25:46]

Dry run: This issue passed the CQ dry run.

[Marijn Kruisselbrink, 2017-02-16 19:50:13]

Using ScriptState instead of Document seems reasonably, I'm not sure if you can
get away with replacing CallWith=ScriptState with always using the scriptstate
for the main world though? Also not sure what you're trying to achieve with
that, as imho the code looks simpler if the ScriptState is just passed in to all
the methods that need it?

https://codereview.chromium.org/2697123003/diff/1/third_party/WebKit/Source/m...
File third_party/WebKit/Source/modules/payments/PaymentRequest.cpp (right):

https://codereview.chromium.org/2697123003/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:652: ScriptState*
scriptState = ScriptState::forMainWorld(frame());
Why is forMainWorld always the correct thing to do here? What if for example an
extension content script creates a PaymentRequest instance and then calls this
method? Before it would use the script state of the isolated world of the
extension, but now this would instead use the script state of the main world?

https://codereview.chromium.org/2697123003/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:828: :
ContextLifecycleObserver(scriptState->getExecutionContext()),
if you're only using the ScriptState to get the ExecutionContext, couldn't this
just be CallWith=ExecutionContext rather than CallWith=ScriptState?

[please use gerrit instead, 2017-02-16 20:52:01]

The CQ bit was checked by rouslan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-16 20:53:11]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[please use gerrit instead, 2017-02-16 21:03:54]

The CQ bit was checked by rouslan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-16 21:04:12]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[please use gerrit instead, 2017-02-16 21:05:47]

Patchset #2 (id:20001) has been deleted

[please use gerrit instead, 2017-02-16 21:06:17]

Description was changed from

==========
Use ScriptState instead of Document in PaymentRequest

Because PaymentRequest is a ContextLifecycleObserver, it always has
access to the current execution context, frame, and script state.
Therefore, it's not necessary to pass ScriptState into every function.

In addition, this patch accepts a ScriptState instead
of a Document in the constructor of PaymentRequest.

The resulting patch reduces the number of lines of code by 28.

BUG=683329
==========

to

==========
Use ExecutionContext instead of Document in PaymentRequest

Because PaymentRequest is a ContextLifecycleObserver, it always has
access to the current execution context, frame, and script state.
Therefore, it's not necessary to pass Document into the constructor.
This patch accepts an ExecutionContext instead of a Document in the
constructor of PaymentRequest.

BUG=683329
==========

[please use gerrit instead, 2017-02-16 21:06:31]

Description was changed from

==========
Use ExecutionContext instead of Document in PaymentRequest

Because PaymentRequest is a ContextLifecycleObserver, it always has
access to the current execution context, frame, and script state.
Therefore, it's not necessary to pass Document into the constructor.
This patch accepts an ExecutionContext instead of a Document in the
constructor of PaymentRequest.

BUG=683329
==========

to

==========
Use ExecutionContext instead of Document in PaymentRequest

Because PaymentRequest is a ContextLifecycleObserver, it always has
access to the current execution context, frame, and script state.
Therefore, it's not necessary to pass Document into the constructor.
This patch accepts an ExecutionContext instead of a Document in the
constructor of PaymentRequest.

BUG=683329
==========

[please use gerrit instead, 2017-02-16 21:11:25]

Marijn, ptal 2nd patch.

https://codereview.chromium.org/2697123003/diff/1/third_party/WebKit/Source/m...
File third_party/WebKit/Source/modules/payments/PaymentRequest.cpp (right):

https://codereview.chromium.org/2697123003/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:652: ScriptState*
scriptState = ScriptState::forMainWorld(frame());
On 2017/02/16 19:50:13, Marijn Kruisselbrink wrote:
> Why is forMainWorld always the correct thing to do here? What if for example
an
> extension content script creates a PaymentRequest instance and then calls this
> method? Before it would use the script state of the isolated world of the
> extension, but now this would instead use the script state of the main world?

Undone.

I'm not familiar with these "worlds", main or otherwise. Can you point me to
anything I can read up on them for future reference?

https://codereview.chromium.org/2697123003/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:828: :
ContextLifecycleObserver(scriptState->getExecutionContext()),
On 2017/02/16 19:50:13, Marijn Kruisselbrink wrote:
> if you're only using the ScriptState to get the ExecutionContext, couldn't
this
> just be CallWith=ExecutionContext rather than CallWith=ScriptState?

Did not know that's possible. Doing that now. Thank you for the tip! :-)

https://codereview.chromium.org/2697123003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/payments/OnPaymentResponseTest.cpp
(right):

https://codereview.chromium.org/2697123003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/payments/OnPaymentResponseTest.cpp:7: #include
<utility>
Moved by clang-format.

[commit-bot: I haz the power, 2017-02-16 22:57:27]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-16 22:57:28]

Dry run: This issue passed the CQ dry run.

[Marijn Kruisselbrink, 2017-02-16 23:55:04]

lgtm

https://chromium.googlesource.com/chromium/src/third_party/+/master/WebKit/So...
seems to explain some about worlds

[haraken, 2017-02-17 01:27:30]

haraken@chromium.org changed reviewers:
+ haraken@chromium.org

[haraken, 2017-02-17 01:27:32]

> Using ScriptState instead of Document seems reasonably, I'm not sure if you
can
> get away with replacing CallWith=ScriptState with always using the scriptstate
> for the main world though? Also not sure what you're trying to achieve with
> that, as imho the code looks simpler if the ScriptState is just passed in to
all
> the methods that need it?

We'd prefer using CallWith=ScriptState than CallWith=ExecutionContext, since
ScriptState has all info about script execution.

See
https://chromium.googlesource.com/chromium/src/third_party/+/master/WebKit/So...

https://codereview.chromium.org/2697123003/diff/1/third_party/WebKit/Source/m...
File third_party/WebKit/Source/modules/payments/PaymentRequest.cpp (right):

https://codereview.chromium.org/2697123003/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:652: ScriptState*
scriptState = ScriptState::forMainWorld(frame());
On 2017/02/16 21:11:24, rouslan wrote:
> On 2017/02/16 19:50:13, Marijn Kruisselbrink wrote:
> > Why is forMainWorld always the correct thing to do here? What if for example
> an
> > extension content script creates a PaymentRequest instance and then calls
this
> > method? Before it would use the script state of the isolated world of the
> > extension, but now this would instead use the script state of the main
world?
> 
> Undone.
> 
> I'm not familiar with these "worlds", main or otherwise. Can you point me to
> anything I can read up on them for future reference?

You're right. It's wrong to assume that this is for the main world.

You should always pass in a correct ScriptState from the caller side (in common
cases from the binding layer by using [CallWith=ScriptState]).

[please use gerrit instead, 2017-02-18 15:27:57]

The CQ bit was checked by rouslan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-18 15:28:08]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-18 17:46:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-18 17:46:58]

Dry run: This issue passed the CQ dry run.

[please use gerrit instead, 2017-02-19 18:53:02]

Ptal patch 3.

https://codereview.chromium.org/2697123003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/payments/PaymentRequest.cpp (right):

https://codereview.chromium.org/2697123003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:907:
ScriptState::forMainWorld(frame()), EventTypeNames::shippingoptionchange);
Is it OK to use the main world when notifying the merchant website that the user
has changed their shipping option? If not, please explain why
getExecutionContext() would be better than ScriptState::forMainWorld() here.

https://codereview.chromium.org/2697123003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.idl
(right):

https://codereview.chromium.org/2697123003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.idl:10:
ConstructorCallWith=ScriptState
Docs say that CallWith=ExecutionContext is deprecated, right?

[Marijn Kruisselbrink, 2017-02-21 19:08:56]

https://codereview.chromium.org/2697123003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/payments/PaymentRequest.cpp (right):

https://codereview.chromium.org/2697123003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:907:
ScriptState::forMainWorld(frame()), EventTypeNames::shippingoptionchange);
On 2017/02/19 at 18:53:02, rouslan wrote:
> Is it OK to use the main world when notifying the merchant website that the
user has changed their shipping option? If not, please explain why
getExecutionContext() would be better than ScriptState::forMainWorld() here.

Even though each world has it's own Window and Document javascript objects,
they're still backed by the same C++ Document instance. So getExecutionContext
is independent of which world you're using. That also means that since you're
only using the script state to then get the execution context, calling
ScriptState::forMainWorld is not wrong in that it will still always result in
the right behavior. It does seem wrong in that you really don't care about the
script state at this point, since all you're really using it for is to get the
correct TaskRunnerHelper, which would be the same for all script states
associated with the same execution context.

So possibly you want ::create methods for both ScriptState and ExecutionContext
in PaymentRequestUpdateEvent so you can use the non-deprcted
callwith=ScriptState for script created events, yet can still pass just the
execution context for c++ created events?

https://codereview.chromium.org/2697123003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.idl
(right):

https://codereview.chromium.org/2697123003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.idl:10:
ConstructorCallWith=ScriptState
On 2017/02/19 at 18:53:02, rouslan wrote:
> Docs say that CallWith=ExecutionContext is deprecated, right?

Yep, seems that way. Although I'm very confused now.

haraken@: in the same BUG that is linked from the CL that updated the
documentation to mark CallWith=ExecutionContext deprecated, you landed another
CL that replaced a whole bunch of CallWith=ScriptState with
CallWith=ExecutionContext, specifically in the payments code? Did you change
your mind in the two hours between landing those CLs?

[haraken, 2017-02-21 23:53:38]

On 2017/02/21 19:08:56, Marijn Kruisselbrink wrote:
>
https://codereview.chromium.org/2697123003/diff/60001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/modules/payments/PaymentRequest.cpp (right):
> 
>
https://codereview.chromium.org/2697123003/diff/60001/third_party/WebKit/Sour...
> third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:907:
> ScriptState::forMainWorld(frame()), EventTypeNames::shippingoptionchange);
> On 2017/02/19 at 18:53:02, rouslan wrote:
> > Is it OK to use the main world when notifying the merchant website that the
> user has changed their shipping option? If not, please explain why
> getExecutionContext() would be better than ScriptState::forMainWorld() here.
> 
> Even though each world has it's own Window and Document javascript objects,
> they're still backed by the same C++ Document instance. So getExecutionContext
> is independent of which world you're using. That also means that since you're
> only using the script state to then get the execution context, calling
> ScriptState::forMainWorld is not wrong in that it will still always result in
> the right behavior. It does seem wrong in that you really don't care about the
> script state at this point, since all you're really using it for is to get the
> correct TaskRunnerHelper, which would be the same for all script states
> associated with the same execution context.
> 
> So possibly you want ::create methods for both ScriptState and
ExecutionContext
> in PaymentRequestUpdateEvent so you can use the non-deprcted
> callwith=ScriptState for script created events, yet can still pass just the
> execution context for c++ created events?
> 
>
https://codereview.chromium.org/2697123003/diff/60001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.idl
> (right):
> 
>
https://codereview.chromium.org/2697123003/diff/60001/third_party/WebKit/Sour...
> third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.idl:10:
> ConstructorCallWith=ScriptState
> On 2017/02/19 at 18:53:02, rouslan wrote:
> > Docs say that CallWith=ExecutionContext is deprecated, right?
> 
> Yep, seems that way. Although I'm very confused now.
> 
> haraken@: in the same BUG that is linked from the CL that updated the
> documentation to mark CallWith=ExecutionContext deprecated, you landed another
> CL that replaced a whole bunch of CallWith=ScriptState with
> CallWith=ExecutionContext, specifically in the payments code? Did you change
> your mind in the two hours between landing those CLs?

Which CL are you talking about?

[Marijn Kruisselbrink, 2017-02-21 23:57:08]

On 2017/02/21 at 23:53:38, haraken wrote:
> On 2017/02/21 19:08:56, Marijn Kruisselbrink wrote:
> > On 2017/02/19 at 18:53:02, rouslan wrote:
> > > Docs say that CallWith=ExecutionContext is deprecated, right?
> > 
> > Yep, seems that way. Although I'm very confused now.
> > 
> > haraken@: in the same BUG that is linked from the CL that updated the
> > documentation to mark CallWith=ExecutionContext deprecated, you landed
another
> > CL that replaced a whole bunch of CallWith=ScriptState with
> > CallWith=ExecutionContext, specifically in the payments code? Did you change
> > your mind in the two hours between landing those CLs?
> 
> Which CL are you talking about?

In https://bugs.chromium.org/p/chromium/issues/detail?id=669812 I see
https://codereview.chromium.org/2541663003 which replaces
ConstructorCallWith=ScriptState with ConstructorCallWith=ExecutionContext in one
class and CallWith=Document in another class, and then two hours later the other
CL where you update the documentation to do the opposite and deprecate
CallWith=ExecutionContext to be replaces with CallWith=ScriptState.

[haraken, 2017-02-22 00:07:07]

On 2017/02/21 23:57:08, Marijn Kruisselbrink wrote:
> On 2017/02/21 at 23:53:38, haraken wrote:
> > On 2017/02/21 19:08:56, Marijn Kruisselbrink wrote:
> > > On 2017/02/19 at 18:53:02, rouslan wrote:
> > > > Docs say that CallWith=ExecutionContext is deprecated, right?
> > > 
> > > Yep, seems that way. Although I'm very confused now.
> > > 
> > > haraken@: in the same BUG that is linked from the CL that updated the
> > > documentation to mark CallWith=ExecutionContext deprecated, you landed
> another
> > > CL that replaced a whole bunch of CallWith=ScriptState with
> > > CallWith=ExecutionContext, specifically in the payments code? Did you
change
> > > your mind in the two hours between landing those CLs?
> > 
> > Which CL are you talking about?
> 
> In https://bugs.chromium.org/p/chromium/issues/detail?id=669812 I see
> https://codereview.chromium.org/2541663003 which replaces
> ConstructorCallWith=ScriptState with ConstructorCallWith=ExecutionContext in
one
> class and CallWith=Document in another class, and then two hours later the
other
> CL where you update the documentation to do the opposite and deprecate
> CallWith=ExecutionContext to be replaces with CallWith=ScriptState.

Ah, sorry about the confusion.

- [ConstructorCallWith=ScriptState] is not encouraged because people sometimes
save the ScriptState in DOM object's constructor and use the ScriptState later.
This is wrong. Alternatively, we should pass in a correct ScriptState by using
[CallWith=ScriptState] at every DOM attribute/method call. That's why I removed
[ConstructorCallWith=ScriptState].

- [CallWith=ScriptState] is encouraged.

(I should have clarified the point in the mark down file...)

[please use gerrit instead, 2017-02-22 17:56:25]

The CQ bit was checked by rouslan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-22 17:57:07]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[please use gerrit instead, 2017-02-22 17:57:08]

Description was changed from

==========
Use ExecutionContext instead of Document in PaymentRequest

Because PaymentRequest is a ContextLifecycleObserver, it always has
access to the current execution context, frame, and script state.
Therefore, it's not necessary to pass Document into the constructor.
This patch accepts an ExecutionContext instead of a Document in the
constructor of PaymentRequest.

BUG=683329
==========

to

==========
Use ExecutionContext instead of Document in PaymentRequest constructor.

BUG=683329
==========

[please use gerrit instead, 2017-02-22 17:59:28]

mek & haraken: ptal patch 4. I've made sure to use ExecutionContext in
constructors and ScriptState in methods. Thank you for the explanations.

[commit-bot: I haz the power, 2017-02-22 18:18:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-22 18:18:41]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)

[please use gerrit instead, 2017-02-22 23:16:36]

Description was changed from

==========
Use ExecutionContext instead of Document in PaymentRequest constructor.

BUG=683329
==========

to

==========
Use ExecutionContext instead of Document in PaymentRequest constructor.

BUG=683329
==========

[haraken, 2017-02-22 23:43:17]

LGTM

[please use gerrit instead, 2017-02-23 14:59:28]

The CQ bit was checked by rouslan@chromium.org

[please use gerrit instead, 2017-02-23 14:59:28]

The patchset sent to the CQ was uploaded after l-g-t-m from mek@chromium.org
Link to the patchset: https://codereview.chromium.org/2697123003/#ps80001
(title: "ExecutionContext in constructor only")

[commit-bot: I haz the power, 2017-02-23 14:59:50]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-23 15:36:42]

CQ is committing da patch.

Bot data: {"patchset_id": 80001, "attempt_start_ts": 1487861968153520,
"parent_rev": "961f09b963688aed198af56e5a369e50351a88d6", "commit_rev":
"a4cf0dc85a9d52d8d1a07ee15ae7bd0c8bc02b06"}

[commit-bot: I haz the power, 2017-02-23 15:37:16]

Description was changed from

==========
Use ExecutionContext instead of Document in PaymentRequest constructor.

BUG=683329
==========

to

==========
Use ExecutionContext instead of Document in PaymentRequest constructor.

BUG=683329

Review-Url: https://codereview.chromium.org/2697123003
Cr-Commit-Position: refs/heads/master@{#452494}
Committed:
https://chromium.googlesource.com/chromium/src/+/a4cf0dc85a9d52d8d1a07ee15ae7...
==========

[commit-bot: I haz the power, 2017-02-23 15:37:17]

Committed patchset #4 (id:80001) as
https://chromium.googlesource.com/chromium/src/+/a4cf0dc85a9d52d8d1a07ee15ae7...