Re: [w3c/payment-request] Dont block UI if .updateWith() not called (closes #589) (#591)

marcoscaceres commented on this pull request.



> @@ -2417,6 +2422,9 @@
             <li>If <var>event</var>'s <a>isTrusted</a> attribute is false, then
             then <a>throw</a> a "<a>InvalidStateError</a>" <a>DOMException</a>.
             </li>
+            <li>If <var>event</var>.<a>[[\didUpdate]]</a> is true, then

> So this would happen if someone calls updateWith(p), p settles, and then someone calls updateWith(q), right?

I was thinking of this case: 

```JS
request.onaddresschange  = ev => { 
   Promise.resolve({...details});
   // next tick, so [[didUpdate]] is now true. Throws InvalidStateError.
   .then(ev.updateWith.bind(ev));
}
```

>Whereas the next line would happen if someone calls updateWith(p), and before p settles, someone calls updateWith(q)?

Correct. It also prevents someone holding a reference to event and calling `.updateWith(p)` after `p` has settled. The problem in the current spec is that [[\waitForUpdate]] and request.[[updating]] are both reset to `false` in step 14 of `updateWith()` - so theoretically, a developer could have just waited this:  

```JS
request.onaddresschange  = async ev => {
   const p =  Promise.resolve({...details});
   ev.updateWith(p);
   await p;  // [[waitForUpdate]] and request.[[updating]] are both reset to `false`! 
   // [[didUpdate]] is true, this now throws
   const q = Promise.resolve({...details});
   ev.updateWith(q);
}
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/pull/591#discussion_r135167916