Open marcoscaceres opened 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
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.
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.
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?)
@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.
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.
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.
@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).
Yes, something like that would work.
Added blockers in the OP.
Hi all. How can we proceed with this PR?
@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.
Hi all, I've started a conversation internally to understand how we can proceed with this and other pull requests.
Brought back the tests https://github.com/web-platform-tests/wpt/pull/44409
@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.
@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.
Blocked also on https://github.com/w3c/contact-picker/pull/74
Need to move more stuff to the Contact Picker spec... the contact picker spec does define how to construct addresses.
@marcoscaceres - Please let me know when this pull-request is reconciled with the changes in the Contact Picker, so I can re-review.
Oops, ignore that last comment. Deleted it!
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