Consider removing requestAutocomplete

[smaug----]

Sounds like blink is removing it, and it has never been enabled in Gecko, as far as I know.
See also https://bugzilla.mozilla.org/show_bug.cgi?id=1270740

[mathiasbynens]

Note that it never shipped in Opera (despite it being in Blink/Chromium feature) — only Chrome shipped it.

Basic Card replaces it.

[danbeam]

requestAutocomplete[1] hasn't seen the adoption we've hoped for. Only Chrome has implemented it, despite Mozilla being interested[2].

Chrome has started removing requestAutocomplete as of today[3], and intends to fully remove the API soon[4].

/cc @zkoch

[1] https://html.spec.whatwg.org/multipage/forms.html#dom-form-requestautocomplete
[2] https://bugzilla.mozilla.org/buglist.cgi?quicksearch=requestAutocomplete
[3] https://groups.google.com/a/chromium.org/d/msg/blink-dev/O9_XnDQh3Yk/SI9yuUpjAwAJ
[4] https://codereview.chromium.org/1958543002/

[mnoorenberghe]

Only Chrome has implemented it, despite Mozilla being interested[2].

Yeah, we (Mozilla) haven't work on it recently though finishing it has been talked about many times over the last six months. Since it's a big project it has been hard getting resources committed. Previous work on it stopped as a higher priority project came up and it didn't get prioritized again. I still think it's a good idea as it's a nice example of progressive enhancement on existing forms and it supports more than just payment information.

Basic Card replaces it.

No it doesn't. Basic Card is only for payments but requestAutocomplete can be used for logins and other non-payment information like email and phone number. It will be sad for the web (developers and users) if sites need to use multiple APIs or a mix of <input> and some payment-specific API to complete a checkout, registration, and/or payment (or some mix of the three which isn't that uncommon).

Some questions:

• What makes us think that the payment request API will get more adoption than requestAutocomplete?
• Why is requestAutocomplete adoption low? Were there implementer concerns? Author concerns?
• Why wasn't the payment request API built on top of rAc since it's mostly a subset with some extra/different returned data which could have been part of the rAc return value?

/cc @rlbmoz

[zkoch]

What makes us think that the payment request API will get more adoption than requestAutocomplete?

This is always a hard question to answer, but a couple of thoughts: 1.) We have multi-browser support early in the process, which sends a strong signal to merchants that might consider implementing. 2.) PaymentRequest allows us to bring better, faster, and more secure forms of payment to the web platform (e.g. things like Apple Pay). 3.) The landscape has changed. Mobile payments have become quite popular over the last couple of years, and we've also seen a resurgence of mobile web sites and a focus on creating great mobile experiences. PaymentRequest is about making sure we also have modern payments on the web as well.

I wrote up a bit more on this in my rationale doc.

Why is requestAutocomplete adoption low? Were there implementer concerns? Author concerns?

No one else implemented it. Why spend the development resources to update your checkout flow for one browser?

Why wasn't the payment request API built on top of rAc since it's mostly a subset with some extra/different returned data which could have been part of the rAc return value?

I actually disagree with the premise of this question. That might be true for basic card payments, but it is not true for all other forms of payment out there (tokenized, closed loop systems, direct bank transfer, etc).

[mnoorenberghe]

What makes us think that the payment request API will get more adoption than requestAutocomplete?

This is always a hard question to answer, but a couple of thoughts: 1.) We have multi-browser support early in the process, which sends a strong signal to merchants that might consider implementing.

This could have also been solved by other browser vendors implementing requestAutocomplete. The API was very simple and I suspect Mozilla and Google would have considered changes if it meant other vendors would be onboard. Perhaps the payment request API was created because there wasn't widespread knowledge of the rAc API (perhaps because it was just part of the HTML spec).

2.) PaymentRequest allows us to bring better, faster, and more secure forms of payment to the web platform (e.g. things like Apple Pay).

The requestAutocomplete API was very simple (one method) so it could have easily been extended/modified to return tokens instead of plaintext credit card numbers.

3.) The landscape has changed. Mobile payments have become quite popular over the last couple of years, and we've also seen a resurgence of mobile web sites and a focus on creating great mobile experiences. PaymentRequest is about making sure we also have modern payments on the web as well.

This doesn't seem new to me as requestAutocomplete was often positioned as an API to help the checkout flow on mobile (there were studies about drop-off rates on mobile checkouts cited in Chrome dev videos and at I/O). IIRC, it was also implemented for Chrome on Android first and Chrome only supported rAc if payment fields were present instead of implementing the API in general. In other words, mobile was the primary motivator for rAc too and payments was the priority for Google's implementation.

I wrote up a bit more on this in my rationale doc.

I disagree with the three points since the spec wasn't set in stone and therefore starting from scratch wasn't required.

Why is requestAutocomplete adoption low? Were there implementer concerns? Author concerns?

No one else implemented it. Why spend the development resources to update your checkout flow for one browser?

requestAutocomplete was made to easily work on top of existing sites without changes to the server-side (receiving the request) or markup (of the requesting page) so the investment was very small to adopt it and the value would be higher checkout conversion rates (especially on mobile). We (Mozilla) did start implementing it but it just wasn't a high priority. I don't know why other vendors didn't implement it. Did they even know about it or consider it or was it forgotten about?

Why wasn't the payment request API built on top of rAc since it's mostly a subset with some extra/different returned data which could have been part of the rAc return value?

I actually disagree with the premise of this question. That might be true for basic card payments, but it is not true for all other forms of payment out there (tokenized, closed loop systems, direct bank transfer, etc).

I don't see how new arguments or Promise resolution values for the requestAutocomplete method couldn't have support non-credit card payment methods in a non-breaking way.