payment-request tests depend on removed basic-card support

[RByers]

Tests in payment-request which depend on having a supported payment method tend to use basic-card and https://apple.com/apple-pay. basic-card is problematic because all browsers dropped support for it years ago. Safari supports only Apple Pay so needs to rely on that method, but this causes network fetches and flakiness in Chrome (proposed fix in #61067).

Since Chromium browsers have no pre-installed payment methods, I think the solution is to replace basic-card with a JIT-installed payment handler (which will be silently ignored by Safari). @stephenmcgruer @marcoscaceres sound OK?

Experimenting with this a bit it seem like it might have some issues in Chrome because many of the tests expect to be able to abort a payment, which once we've loaded a payment handler we can't necessarily do in chrome (for privacy reasons I believe). The right fix is probably WebDriver automation for PaymentRequest (#15349), but that's a bigger lift. It looks like we can probably make it work by having the tests supporting two payment methods and relying on browser payment method selector UI playing the same role as Safari's ApplePay sheet (browser UI which can be aborted by the tests). It's a bit hacky, but would get the tests passing again. @stephenmcgruer WDYT?

[marcoscaceres]

I think this might be ok, but yeah… the right fix will be to use virtual wallets and instruments via Web Driver. Unblocking Chrome and getting rid of basic-card is definitely worth while if Chrome needs it.

But, do we want to spend energy/time/tokens on this or should we just do the Web Driver BiDi solution? It turned out to be very simple to spec and implement for the DC API, so we could replicate what we did there.

[RByers]

Thanks Marcos. We'd still need much of this with the virtual wallet solution (just probably one instead of two). So personally I'd suggest we land this first. I don't know if/when we'll have cycles for investing in the chromedriver changes necessary (@stephenmcgruer?), though maybe it would be simple for @mohamedamir to just replicate what he's done for DC for PR as well.

If you prefer I'm happy. landing a single handler version of this PR, which will leave the tests still failing on chrome but closer to where we need to be.

[stephenmcgruer]

Thanks Rick for filing this! It's long overdue that the payment-request (and web-based-payment-handler) WPTs got some TLC, and that's my bad :(. But very happy that you're looking at it ❤️

We definitely need to build a proper webdriver testing infra for Payment Request, and I'm excited that bidi is here nowadays which makes that much more feasible, but I suspect that will be quite complex. It's going to force us to look critically at what is actually defined in the Payment Request spec vs what browsers actually do today, decide on how to deal with things like Chrome's browser-level UX, etc. So I'm aligned with Rick to at least land the patch in #61069, it seems pretty clean to me and fixes most of the tests. Then we probably shouldn't put effort into 'hacks' for the remaining tests, but instead try to prioritize working on a webdriver layer.

I don't know if/when we'll have cycles for investing in the chromedriver changes necessary (@stephenmcgruer?),

Not sure. I hope we can make an argument for this (and SPC webdriver support) in H2, but we'll see how things shake out.