w3c / payment-request

Payment Request API
https://www.w3.org/TR/payment-request-1.1/
Other
482 stars 183 forks source link

Revert "Drop PaymentAddress, shipping + billing address support (#955)" #996

Open marcoscaceres opened 1 year ago

marcoscaceres commented 1 year ago

This reverts commit 486c07ae494ac64a31d7f90cf9df026b4250e878.

Bringing back addresses so we can continue to figure out a path forward (given it's now a interop issue)

closes #???

Blocked on:

The following tasks have been completed:

Implementation commitment:

Optional, impact on Payment Handler spec?


Preview | Diff

ianbjacobs commented 1 year ago

Hi @marcoscaceres,

From recent discussion [1] the expectation is to bring these back as deprecated features. Please don't merge as-is; could you suggest some deprecation text? (Or I can work with you on this next week.)

Ian

[1] https://www.w3.org/2022/09/13-wpwg-minutes.html#t01

marcoscaceres commented 1 year ago

Sorry, I wasn't in the discussion at the F2F, but I don't agree they would be deprecated (we still expect shipping addresses to work, right? users/merchant still ship physical good and the API doesn't provide any other alternatives that would deprecate this feature). I think we should get this back into the spec and then actively work to address the privacy concerns.

stephenmcgruer commented 1 year ago

Sorry, I wasn't in the discussion at the F2F, but I don't agree they would be deprecated (we still expect shipping addresses to work, right? users/merchant still ship physical good and the API doesn't provide any other alternatives that would deprecate this feature). I think we should get this back into the spec and then actively work to address the privacy concerns.

From the Chrome side, we aren't too bothered by what form the spec text takes (i.e. an addendum, a note, marked deprecated or not), but we are aligned in wanting it back in some form as it is shipping and used today.

We are still investigating on our side to what extent it is used by web developers, and how feasible a deprecation + removal process would be. Hope to have results by end of year on that.

marcoscaceres commented 1 year ago

I'm still at a loss about the deprecation (or designation) without an alternative format for shipping addressed? is there a real incentive to remove shipping address support for some reason? (maybe I missed the memo?)

ianbjacobs commented 1 year ago

@marcoscaceres, we went through a process to remove the feature. I do not think we should simply re-introduce it. I look forward to discussing as soon as next week.

marcoscaceres commented 1 year ago

I'm happy to add a note saying we will work towards addressing the privacy issues. That should get us back to where we were and allows us to continue involving the feature while also managing any compatibility issues.

marcoscaceres commented 1 year ago

Doing more investigation, I just remembered that PaymentAddress became ContactAddress in the Contact Picker API, so we can drop the whole Physical Addresses section.

The privacy issues remain, but issues with physical addresses are now the concern of Contact Picker API, which, at least procedurally much easier.

ianbjacobs commented 1 year ago

@marcoscaceres wrote: "I'm happy to add a note saying we will work towards addressing the privacy issues. "

Would something like this work?

The Web Payments Working Group removed support for shipping and billing addresses from the original version of Payment Request API due to privacy issues; see issue 842. In order to provide documentation for implementations that continue to support this capability, the Working Group is now restoring the feature with an expectation of addressing privacy issues. In doing so the Working Group may also make changes to Payment Request API based on the evolution of other APIs (e.g., the Content Picker API).

marcoscaceres commented 1 year ago

Yes, something like that would work.

marcoscaceres commented 1 year ago

Added blockers in the OP.

dmengelt commented 1 year ago

Hi all. How can we proceed with this PR?

rsolomakhin commented 1 year ago

@stephenmcgruer wrote:

We are still investigating on our side to what extent it is used by web developers, and how feasible a deprecation + removal process would be. Hope to have results by end of year on that.

Our investigations show that a significant portion of web developers are using shipping and contact info, so we are still in favor of bringing this back.

ianbjacobs commented 1 year ago

Hi all, I've started a conversation internally to understand how we can proceed with this and other pull requests.

marcoscaceres commented 4 months ago

Brought back the tests https://github.com/web-platform-tests/wpt/pull/44409

marcoscaceres commented 4 months ago

@rsolomakhin, @stephenmcgruer, we might consider some kind of transitional strategy amongst ourselves to check how much potential web compat breakage there could be from switching PaymentAddress to ContactAddress... I don't imagine there will be much, but it's likely we will break at least someone.

marcoscaceres commented 4 months ago

Blocked on https://github.com/w3c/payment-request/pull/1021

stephenmcgruer commented 4 months ago

@rsolomakhin, @stephenmcgruer, we might consider some kind of transitional strategy amongst ourselves to check how much potential web compat breakage there could be from switching PaymentAddress to ContactAddress... I don't imagine there will be much, but it's likely we will break at least someone.

Hrm, yep, that's a fun one. I'm not sure offhand how we might build a UseCounter (in Chrome) for access to it in a way that matters (e.g., checking typeof) versus doesn't (accessing members). It should be possible, not sure if it'll be worth the effort. We can also do compat searches of GitHub or Web Archive, though I suspect that most checkout code isn't visible in either :(. (https://www.chromium.org/blink/platform-predictability/compat-tools/)

On the Chrome side, we would of course do that change as a deprecation / removal, so there'd at least be a warning period for developers.

marcoscaceres commented 4 months ago

Blocked also on https://github.com/w3c/contact-picker/pull/74

marcoscaceres commented 4 months ago

Need to move more stuff to the Contact Picker spec... the contact picker spec does define how to construct addresses.

rsolomakhin commented 4 months ago

@marcoscaceres - Please let me know when this pull-request is reconciled with the changes in the Contact Picker, so I can re-review.

marcoscaceres commented 2 months ago

Oops, ignore that last comment. Deleted it!