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

marcoscaceres · 2022-09-20T23:51:02Z

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 #???

Blocked on:

Contacts being published FPWD Request for Contacts Picker API transitions#457
bring back the tests.
Revert spec to REC state #1021

The following tasks have been completed:

Modified Web platform tests

Implementation commitment:

WebKit
Chromium
Gecko (link to issue)

Optional, impact on Payment Handler spec?

Preview | Diff

ianbjacobs · 2022-09-21T03:51:14Z

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 · 2022-09-21T19:04:42Z

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 · 2022-09-22T15:51:38Z

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 · 2022-09-22T23:52:21Z

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 · 2022-09-22T23:59:10Z

@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 · 2022-09-23T01:36:30Z

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 · 2022-09-23T01:50:56Z

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 · 2022-09-26T21:08:56Z

@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 · 2022-10-07T04:06:24Z

Yes, something like that would work.

marcoscaceres · 2022-11-14T23:17:57Z

Added blockers in the OP.

dmengelt · 2023-06-05T11:59:09Z

Hi all. How can we proceed with this PR?

rsolomakhin · 2023-06-05T12:54:36Z

@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 · 2023-06-05T15:05:34Z

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

This reverts commit 486c07a.

marcoscaceres · 2024-02-05T22:39:16Z

Brought back the tests web-platform-tests/wpt#44409

marcoscaceres · 2024-02-05T22:47:11Z

@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 · 2024-02-06T01:22:47Z

Blocked on #1021

ianbjacobs · 2024-05-13T23:11:09Z

index.html

+          display this option by default in the user interface.
+        </dd>
+      </dl>
+    </section>


marcoscaceres · 2024-05-14T01:47:06Z

index.html

@@ -1989,6 +2505,35 @@ <h2>
          </li>
          <li>If |errorFields:PaymentValidationErrors| was passed:
            <ol>
+              <li>Optionally, show a warning in the developer console if any of


marcoscaceres · 2024-05-14T01:47:17Z

index.html

              DOMString error;
              object paymentMethod;
            };
          </pre>
          <dl>
+            <dt>


marcoscaceres · 2024-05-14T01:48:28Z

index.html

-          <dfn>details</dfn> attribute
-        </h2>
-        <p>
+        <section data-dfn-for="PayerErrors">


index.html

marcoscaceres · 2024-05-14T01:49:54Z

index.html

@@ -2136,6 +2753,66 @@ <h2>
          </p>
        </aside>
      </section>
+      <section>


marcoscaceres · 2024-05-14T01:50:03Z

index.html

+          [=shipping address=] chosen by the user.
+        </p>
+      </section>
+      <section>


marcoscaceres · 2024-05-14T01:50:24Z

index.html

+          option.
+        </p>
+      </section>
+      <section>


marcoscaceres · 2024-05-14T01:50:32Z

index.html

+          user.
+        </p>
+      </section>
+      <section>


marcoscaceres · 2024-05-14T01:50:39Z

index.html

+          by the user.
+        </p>
+      </section>
+      <section>


marcoscaceres · 2024-05-14T01:50:52Z

index.html

@@ -2257,6 +2934,14 @@ <h2>
          </li>
        </ol>
      </section>
+      <section data-dfn-for="PaymentResponse">


marcoscaceres · 2024-05-20T22:14:53Z

index.html

+        </pre>
+        <p>
+          The members of the {{AddressErrors}} dictionary represent validation
+          errors with specific parts of a <a>physical address</a>. Each


Suggested change

errors with specific parts of a <a>physical address</a>. Each

errors with specific parts of a [=physical address=]. Each

marcoscaceres · 2024-05-20T22:17:34Z

index.html

+            <dfn>addressLine</dfn> member
+          </dt>
+          <dd>
+            Denotes that the <a>address line</a> has a validation error. In the


Suggested change

Denotes that the <a>address line</a> has a validation error. In the

Denotes that the [=physical address/address line=] has a validation error. In the

marcoscaceres · 2024-05-20T22:17:53Z

index.html

+            <dfn>city</dfn> member
+          </dt>
+          <dd>
+            Denotes that the <a>city</a> has a validation error. In the user


Suggested change

Denotes that the <a>city</a> has a validation error. In the user

Denotes that the [=physical address/city=] has a validation error. In the user

marcoscaceres · 2024-05-20T22:18:23Z

index.html

+            <dfn>country</dfn> member
+          </dt>
+          <dd>
+            Denotes that the <a>country</a> has a validation error. In the user


Suggested change

Denotes that the <a>country</a> has a validation error. In the user

Denotes that the [=physical address/country=] has a validation error. In the user

marcoscaceres · 2024-05-20T22:18:56Z

index.html

+            <dfn>dependentLocality</dfn> member
+          </dt>
+          <dd>
+            Denotes that the <a>dependent locality</a> has a validation error.


Suggested change

Denotes that the <a>dependent locality</a> has a validation error.

Denotes that the [=physical address/dependent locality=] has a validation error.

marcoscaceres · 2024-05-20T22:19:14Z

index.html

+            <dfn>organization</dfn> member
+          </dt>
+          <dd>
+            Denotes that the <a>organization</a> has a validation error. In the


Suggested change

Denotes that the <a>organization</a> has a validation error. In the

Denotes that the [=physical address/organization=] has a validation error. In the

marcoscaceres · 2024-05-20T22:19:31Z

index.html

+            <dfn>phone</dfn> member
+          </dt>
+          <dd>
+            Denotes that the <a>phone number</a> has a validation error. In the


Suggested change

Denotes that the <a>phone number</a> has a validation error. In the

Denotes that the [=physical address/phone number=] has a validation error. In the

marcoscaceres · 2024-05-20T22:19:46Z

index.html

+            <dfn>postalCode</dfn> member
+          </dt>
+          <dd>
+            Denotes that the <a>postal code</a> has a validation error. In the


Suggested change

Denotes that the <a>postal code</a> has a validation error. In the

Denotes that the [=physical address/postal code=] has a validation error. In the

marcoscaceres · 2024-05-20T22:20:01Z

index.html

+            <dfn>recipient</dfn> member
+          </dt>
+          <dd>
+            Denotes that the <a>recipient</a> has a validation error. In the


Suggested change

Denotes that the <a>recipient</a> has a validation error. In the

Denotes that the [=physical address/recipient=] has a validation error. In the

marcoscaceres · 2024-05-20T22:20:15Z

index.html

+            <dfn>region</dfn> member
+          </dt>
+          <dd>
+            Denotes that the <a>region</a> has a validation error. In the user


Suggested change

Denotes that the <a>region</a> has a validation error. In the user

Denotes that the [=physical address/region=] has a validation error. In the user

marcoscaceres · 2024-05-20T22:20:28Z

index.html

+            <dfn>sortingCode</dfn> member
+          </dt>
+          <dd>
+            The <a>sorting code</a> has a validation error. In the user agent's


Suggested change

The <a>sorting code</a> has a validation error. In the user agent's

The [=physical address/sorting code=] has a validation error. In the user agent's

marcoscaceres · 2024-05-20T22:21:26Z

index.html

+        <p>
+          The steps to <dfn data-export="">create a `ContactAddress` from
+          user-provided input</dfn> are given by the following algorithm. The
+          algorithm takes a <a>list</a> |redactList|.


Suggested change

algorithm takes a <a>list</a> |redactList|.

algorithm takes a [=list=] |redactList:list|.

marcoscaceres · 2024-05-20T22:22:03Z

index.html

+            are so fine-grained that they can uniquely identify a recipient.
+          </p>
+        </div>
+        <ol>


Suggested change

<ol>

<ol class="algorithm">

marcoscaceres · 2024-05-20T22:24:33Z

index.html

+          <li>Let |details:AddressInit| be a newly created {{AddressInit}}
+          dictionary.
+          </li>
+          <li>If "addressLine" is not in |redactList|, set


Make this into a switch statement off each redactList value, and pop as you go... weeeee

marcoscaceres · 2024-05-20T22:25:12Z

index.html

+          </dd>
+        </dl>
+      </section>
+      <section>


Consider moving all this to the other spec...

marcoscaceres · 2024-05-20T22:26:43Z

index.html

@@ -2350,6 +3379,49 @@ <h2>
              Target
            </th>
          </tr>
+          <tr>


marcoscaceres · 2024-05-20T22:26:58Z

index.html

@@ -2481,13 +3553,50 @@ <h2>
              changes made by the end user through the UI), developers need to
              immediately call {{PaymentRequestUpdateEvent/updateWith()}}.
            </p>
+            <pre class="example js" title=


marcoscaceres · 2024-05-20T22:29:02Z

index.html

+              steps to <a>create a `ContactAddress` from user-provided
+              input</a> with |redactList|.


Suggested change

steps to <a>create a `ContactAddress` from user-provided

input</a> with |redactList|.

steps to [=create a `ContactAddress` from user-provided

input=] with |redactList|.

marcoscaceres force-pushed the bring_back_addresses branch 2 times, most recently from 4027a43 to 7bdd13c Compare September 21, 2022 00:15

anssiko mentioned this pull request Nov 11, 2022

FPWD Request for Contacts Picker API w3c/transitions#457

Closed

ianbjacobs approved these changes Nov 11, 2022

View reviewed changes

marcoscaceres added the Blocked label Nov 14, 2022

ianbjacobs mentioned this pull request Jan 11, 2023

Bring back shipping and contact information. w3c/payment-handler#406

Merged

rsolomakhin mentioned this pull request Jan 12, 2023

Update payment articles GoogleChrome/web.dev#9380

Merged

stephenmcgruer mentioned this pull request Apr 12, 2023

Broken references in Payment Handler API w3c/payment-handler#412

Open

14 tasks

marcoscaceres added 3 commits February 6, 2024 09:17

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

ce4a1ab

This reverts commit 486c07a.

Use ContactAddress instead

aa42cd9

Add note about bring back addresses

f182ffc

marcoscaceres force-pushed the bring_back_addresses branch from fa67a26 to f182ffc Compare February 5, 2024 22:17

marcoscaceres mentioned this pull request Feb 5, 2024

Revert "Remove shipping related things from payment-request (#28830)" web-platform-tests/wpt#44409

Merged

Fix some respec errors

9388e99

ianbjacobs reviewed May 13, 2024

View reviewed changes

index.html

display this option by default in the user interface.

</dd>

</dl>

</section>

Copy link

Collaborator

ianbjacobs May 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅