Revert "Drop PaymentAddress, shipping + billing address support (#955)" #996
Conversation
marcoscaceres
force-pushed
the
bring_back_addresses
branch
2 times, most recently
from
4027a43 to
7bdd13c
Compare
|
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. |
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 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:
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, |
marcoscaceres
force-pushed
the
bring_back_addresses
branch
from
fa67a26 to
f182ffc
Compare
|
Brought back the tests web-platform-tests/wpt#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 |
|
Blocked on #1021 |
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. |
index.html
Outdated
| </dd> | ||
| </dl> | ||
| </section> | ||
| <section> |
There was a problem hiding this comment.
Consider moving all this to the other spec...
| </p> | ||
| <ul> |
There was a problem hiding this comment.
Maybe move to other spec? I think this might be fine though..
| When setting the {{PaymentResponse/payerPhone}} value, the user agent | ||
| SHOULD format the phone number to adhere to [[E.164]]. |
There was a problem hiding this comment.
Need to check if Contact picker handles the formatting....
marcoscaceres
force-pushed
the
bring_back_addresses
branch
from
dc51fa9 to
ad07ae5
Compare
marcoscaceres
force-pushed
the
bring_back_addresses
branch
from
c348f55 to
120d612
Compare
|
@marcoscaceres, now that we've published the CRs, what is the fate of this pull request? |
|
It's ready to merge I believe. Merge #1027 first, and then hopefully this will show up on TR right away |
This reverts commit 486c07a.
Bringing back addresses so we can continue to figure out a path forward (given it's now a interop issue)
closes #996
Blocked on:
The following tasks have been completed:
Implementation commitment:
Optional, impact on Payment Handler spec?
Preview | Diff