Thank you for the report. I will look into it.

This is happening because updateWith() in the handler stops event propagation, so the listeners don't get fired after the handler. Not supposed to happen?

The "immediate" propagation is stopped in the code.

Marijn: Do you know much about immediate event propagation? The PR spec says:

"Set event's stop propagation flag and stop immediate propagation flag."

https://w3c.github.io/payment-request/#idl-def-paymentrequestupdateevent-updatewith(detailspromise)

It's relying on the DOM spec to resume immediate event propagation per:

https://dom.spec.whatwg.org/#dispatching-events

Blink does this in EventDispatcher::DispatchEventPostProcess, but that appears to be too late for us:

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/events/EventDispatcher.cpp?rcl=defd75b9fb377e866044db43128cd2d9f366f17d&l=272

Do you know why that could be happening? I certainly could re-enable immediate event propagation in PaymentRequestUpdateEvent::OnUpdatePaymentDetails, but I'm not sure whether that would be correct.

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp?rcl=3131414035a033d1fb624913474dbdac04158198&l=132

As you point out, the spec says to stop (immediate) event propagation when updateWith is called, so it seems like our implementation matches the spec (and the test doesn't match the spec). So doesn't seem like there is anything wrong here? (other than the test that is)

Marcos: You wrote both the spec and the test. Is there a discrepancy? 

We might need to bring in Domenic here (`git blame` on the spec blames him for this one 😸) - but I'm sure he had a good reason for setting both propagation flags. 

Personally, I think it would be weird/racy for developers if not all listeners get called, so this might be a spec bug? 

Domenic: Please see Marcos's comment #7.

I believe the idea is that, like with other updateWith()-esque methods, once one listener has updated, other listeners can't interfere. It's "first past the post", so to speak.

What would you expect to happen if two listeners called updateWith()?

First one wins, other throws. But I was thinking that being notified that the address or shipping option has changed is useful on its own, even if the second one doesn’t call .updateWith().

I’ve given this more thought and now agree we should change the test to match the spec. There is no case that can’t be covered by having the single handler. 

Apologies for the noise - will get that fixed up in the next few days.

Filed https://github.com/w3c/web-platform-tests/issues/7516 

Please feel free to close this bug as invalid. 

Thank you for the clarification.