Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add paymentmethodchange event #695

Merged
merged 19 commits into from
Jun 21, 2018
Merged

add paymentmethodchange event #695

Changes from all commits
Commits
Show all changes
19 commits
Select commit Hold shift + click to select a range
220eedd
WIP: add paymentmethodchanged event (closes #662)
marcoscaceres Jan 23, 2018
6983c75
WIP
marcoscaceres Jan 23, 2018
0c7fc04
wip
marcoscaceres Apr 3, 2018
7b3fc32
Move attributes to PaymentRequest
marcoscaceres Apr 4, 2018
18a4131
add PR.onpaymentmethodchanged
marcoscaceres Apr 30, 2018
9967b58
fixup hook terminology
marcoscaceres Apr 30, 2018
c0a961f
fix respec warning
marcoscaceres Apr 30, 2018
dbaaa63
Fixup algorithms/steps mess
marcoscaceres May 9, 2018
1837a76
s/paymentmethodchanged/paymentmethodchange
marcoscaceres May 10, 2018
4cb9a43
Null out methodName + methodDetails when things change
marcoscaceres May 10, 2018
f492a24
link tests
marcoscaceres May 10, 2018
aa7f155
Defining payment method changed steps is optional
marcoscaceres May 10, 2018
68217a3
use dot notation for internal slots
marcoscaceres May 10, 2018
dfcb317
refactor to PaymentMethodChangeEvent
marcoscaceres May 17, 2018
6f28026
cleaup
marcoscaceres May 17, 2018
e535034
method name passed as an argument
marcoscaceres May 17, 2018
04bc08e
review nits/typos
marcoscaceres Jun 6, 2018
bd8a06e
review feedback
marcoscaceres Jun 6, 2018
6a79bfb
review fixes
marcoscaceres Jun 12, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
148 changes: 141 additions & 7 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -171,7 +171,7 @@ <h2>
</p>
<dl>
<dt>
A <dfn>can make payment</dfn> algorithm:
<dfn>Steps to check if a payment can be made</dfn>:
</dt>
<dd>
How a payment handler determines whether it, or the user, can
Expand All @@ -184,14 +184,23 @@ <h2>
<dfn>Steps to respond to a payment request</dfn>:
</dt>
<dd>
An algorithm that returns an object or <a data-cite=
Steps that return an object or <a data-cite=
"!WEBIDL#idl-dictionary">dictionary</a> that a merchant uses to
process or validate the transaction. The structure of this object is
specific to each <a>payment method</a>. For an example of such an
object, see the <code><a data-cite=
"payment-method-basic-card#dom-basiccardresponse">BasicCardResponse</a></code>
dictionary of [[payment-method-basic-card]].
</dd>
<dt>
<dfn>Steps for when a user changes payment method</dfn> (optional)
</dt>
<dd>
Steps that describe how to handle the user changing payment method or
monetary instrument (e.g., from a debit card to a credit card) that
results in a <a data-cite="!WEBIDL#idl-dictionary">dictionary</a> or
<a data-cite="!WEBIDL#idl-object">object</a> or null.
</dd>
</dl>
<p>
This API also enables web sites to take advantage of more secure
Expand Down Expand Up @@ -575,8 +584,8 @@ <h2>
readonly attribute PaymentShippingType? shippingType;

attribute EventHandler onshippingaddresschange;

attribute EventHandler onshippingoptionchange;
attribute EventHandler onpaymentmethodchange;
};
</pre>
<div class="note">
Expand Down Expand Up @@ -997,8 +1006,8 @@ <h2>
<li>For each <var>handler</var> in <var>registeredHandlers</var>:
<ol>
<li>Let <var>canMakePayment</var> be the result of running
<var>handler</var>'s <a>can make payment</a> algorithm with
<var>data</var>.
<var>handler</var>'s <a>steps to check if a payment can be
made</a> with <var>data</var>.
</li>
<li>If <var>canMakePayment</var> is true, then append
<var>handler</var> to <var>handlers</var>.
Expand Down Expand Up @@ -1218,8 +1227,8 @@ <h2>
<li>For each <var>handler</var> in <var>handlers</var>:
<ol>
<li>Let <var>canMakePayment</var> be the result of running
<var>handler</var>'s <a>can make payment</a> algorithm with
<var>data</var>.
<var>handler</var>'s <a>steps to check if a payment can be
made</a> with <var>data</var>.
</li>
<li>If <var>canMakePayment</var> is true, resolve
<var>promise</var> with true, and return.
Expand Down Expand Up @@ -1291,6 +1300,16 @@ <h2>
<a>shippingoptionchange</a>.
</p>
</section>
<section data-dfn-for="PaymentRequest" data-link-for="PaymentRequest">
<h2>
<dfn>onpaymentmethodchange</dfn> attribute
</h2>
<p data-tests="onpaymentmenthodchange-attribute.https.html">
A <a>PaymentRequest</a>'s <a>onpaymentmethodchange</a> attribute is
an <a>EventHandler</a> for a <a>PaymentRequestUpdateEvent</a> named
"<a>paymentmethodchange</a>".
</p>
</section>
<section>
<h2>
Internal Slots
Expand Down Expand Up @@ -3401,8 +3420,80 @@ <h2>
The user chooses a new shipping option.
</td>
</tr>
<tr>
<td>
<code><dfn>paymentmethodchange</dfn></code>
</td>
<td>
<a>PaymentMethodChangeEvent</a>
</td>
<td>
The user chooses a different <a>payment method</a> within a
<a>payment handler</a>.
</td>
</tr>
</table>
</section>
<section data-dfn-for="PaymentMethodChangeEvent" data-link-for=
"PaymentMethodChangeEvent">
<h2>
<dfn>PaymentMethodChangeEvent</dfn> interface
</h2>
<pre class="idl">
[Constructor(DOMString type, optional PaymentMethodChangeEventInit eventInitDict), SecureContext, Exposed=Window]
interface PaymentMethodChangeEvent : PaymentRequestUpdateEvent {
readonly attribute DOMString methodName;
readonly attribute object? methodDetails;
};
</pre>
<section>
<h2>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Soooo I know it goes against all previous advice and good sense, but currently for events we don't use internal slots :(. Instead we use the old-style, terrible, "When getting, returns the value it was initialized with". I think making this less terrible is mostly tracked by whatwg/dom#364, /cc @annevk. But in the end we do want to end up in a world that doesn't require people to explicitly define slots and return them for every event property, so I would take the slots out for now. Especially since nothing in this spec sets them.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Um, ok... um... we kinda added internal slots PaymentRequestUpdateEvent also.

I guess I should remove and rephrase those too?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, that one makes sense, as its not exposed. It's the ones that are 1:1 with public properties that are less-good.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, got it. Ok :)

<dfn>methodDetails</dfn> attribute
</h2>
<p data-link-for="PaymentMethodChangeEventInit">
When getting, returns the value it was initialized with. See
<a>methodDetails</a> member of <a>PaymentMethodChangeEventInit</a>
for more information.
</p>
</section>
<section>
<h2>
<dfn>methodName</dfn> attribute
</h2>
<p data-link-for="PaymentMethodChangeEventInit">
When getting, returns the value it was initialized with. See
<a>methodName</a> member of <a>PaymentMethodChangeEventInit</a> for
more information.
</p>
</section>
<section data-dfn-for="PaymentMethodChangeEventInit" data-link-for=
"PaymentMethodChangeEventInit">
<h3>
<dfn>PaymentMethodChangeEventInit</dfn> dictionary
</h3>
<pre class="idl">
dictionary PaymentMethodChangeEventInit : PaymentRequestUpdateEventInit {
required DOMString methodName;
object? methodDetails;
};
</pre>
<dl>
<dt>
<dfn>methodName</dfn> member
</dt>
<dd>
A DOMString representing the <a>payment method identifier</a>.
</dd>
<dt>
<dfn>methodDetails</dfn> member
</dt>
<dd>
An object representing the some data from the payment method, or
null.
</dd>
</dl>
</section>
</section>
<section data-dfn-for="PaymentRequestUpdateEvent" data-link-for=
"PaymentRequestUpdateEvent">
<h2>
Expand Down Expand Up @@ -3671,6 +3762,49 @@ <h2>
</li>
</ol>
</section>
<section>
<h2>
Payment method changed algorithm
</h2>
<p>
A <a>payment handler</a> MAY run the <dfn>payment method changed
algorithm</dfn> when the user changes <a>payment method</a> with
<var>methodDetails</var>, which is either <a data-cite=
"!WEBIDL#idl-dictionary">dictionary</a> or an <a data-cite=
"!WEBIDL#idl-object">object</a> or null, and a <var>methodName</var>,
which is a DOMString that represents the <a>payment method
identifier</a> of the <a>payment handler</a> the user is interacting
with:
</p>
<ol class="algorithm">
<li>Let <var>request</var> be the <a>PaymentRequest</a> object that
the user is interacting with.
</li>
<li>
<a>Queue a task</a> on the <a>user interaction task source</a> to
run the following steps:
<ol>
<li>If the <var>request</var>.<a>[[\updating]]</a> is true, then
terminate this algorithm and take no further action. Only one
update may take place at a time. The <a>user agent</a> SHOULD
ensure that this never occurs.
</li>
<li>If the <var>request</var>.<a>[[\state]]</a> is not set to
"<a>interactive</a>", then terminate this algorithm and take no
further action. The <a>user agent</a> user interface SHOULD
ensure that this never occurs.
</li>
<li data-link-for="PaymentMethodChangeEvent">
<a>Fire an event</a> named "<a>paymentmethodchange</a>" at
<var>request</var> using <a>PaymentMethodChangeEvent</a>, with
its <a>methodName</a> attribute initialized to
<var>methodName</var>, and its <a>methodDetails</a> attribute
initialized to <var>methodDetails</var>.
</li>
</ol>
</li>
</ol>
</section>
<section>
<h2>
PaymentRequest updated algorithm
Expand Down