Intent to deprecate and remove: PaymentAddress.careOf

[Jinho Bang]

Primary eng (and PM emails)

jinho...@samsung.com, rou...@chromium.org

Summary

The attribute was removed from the payment request API spec.

Motivation

The PaymentAddress interface has a careOf field which is non-standard (no well-known address

standards support it, see below). The careOf field is unnecessary, the recipient and organization fields

sufficiently support all necessary use cases. Adding careOf poses significant issues in terms of

interoperability with existing postal address schemas and APIs.

(From spec discussion: https://github.com/w3c/browser-payment-api/issues/244)

Compatibility Risk

Low; Chrome 53 for android is a first browser to support the payment request.

(It was release two days ago.)

User and JS author can’t handle the attribute anyway because current implementation doesn't provide

any UI to set the attribute yet.

Alternative implementation suggestion for web developers

Unnecessary;

Current implementation doesn't provide any UI for inputting the attribute.

Usage information from UseCounter

There is no public UseCounter but Chrome 53 for android(including PaymentRequest API) was

release on 09/16. Also, user and JS author can’t handle the attribute anyway because current

implementation doesn't provide any UI to set the attribute yet.

OWP launch tracking bug

http://crbug.com/648049

Entry on the faeture dashboard

https://www.chromestatus.com/features/5639348045217792

Requesting approval to remove too?

Yes

[Philip Jägenstedt]

The attribute is mentioned in the Payment Request API integration guide, can you get in touch with the right people to make sure it's removed from there and any other documentation that might mention it?

BTW, that the toDict helper is needed at all seems weird, is it a workaround for the fact that Blink's PaymentAddress.idl is missing serializer = {attribute}? PaymentResponse is also missing it.

I took a look in cs.chromium.org, but it's not clear to me how PaymentAddress is populated. Is "any UI for inputting the attribute" the only way it could be non-empty? If so I think removal without deprecation makes sense given how new it is, but an example of how PaymentAddress would be used in the wild would be nice.

[Jinho Bang]

2016년 9월 19일 월요일 오후 5시 43분 15초 UTC+9, Philip Jägenstedt 님의 말:

The attribute is mentioned in the Payment Request API integration guide, can you get in touch with the right people to make sure it's removed from there and any other documentation that might mention it?

zkoch@ is one of the authors. I'll request it to him.

 

BTW, that the toDict helper is needed at all seems weird, is it a workaround for the fact that Blink's PaymentAddress.idl is missing serializer = {attribute}? PaymentResponse is also missing it.

The serializer was added to the spec three days ago.

Please see: https://github.com/w3c/browser-payment-api/pull/252

Also, I already started to work on this yesterday. (WIP CL: https://codereview.chromium.org/2349133002)

 

I took a look in cs.chromium.org, but it's not clear to me how PaymentAddress is populated. Is "any UI for inputting the attribute" the only way it could be non-empty? If so I think removal without deprecation makes sense given how new it is, but an example of how PaymentAddress would be used in the wild would be nice.

Exactly. "any UI for inputting the attribute" is the only way it could be non-empty.

I can't show you any example in code level because there is no way to populate PaymentAddress.

Instead I'll explain the payment request process in code level.

// create payment request

var pr = new PaymentRequest(..., ..., { requestShipping: true });

// Show payment sheet UI and then collect some information for payment. (e.g. address, card number and so on)

var uiPromise = pr.show();

// If the UI is closed, uiPromise will be resolved with PaymentResponse.

// The response has non-null shippingAddress attribute if requestShipping is true.

// The shippingAddress is only populated from the user input at UI.

// There is no way to create PaymentAddress object in code level.

uiPromise.then((response) => {

    // Currently, Chrome doesn't support any input field for 'careOf' attribute on AddressEditor UI.

    // So, response.shippingAddress.careOf is always empty string.

    assert response.shippingAddress.careOf == "";

});

[Philip Jägenstedt]

Thanks Jinho for taking care of all that, the code example was helpful.

Given that the attribute is always empty, would there be any harm in deprecating now and removing in M56? For anyone who has copied from the article, that might save them the effort of later understanding why { careOf: undefined } is in their dict.

I'm also curious if there are any other attributes on PaymentAddress which are always empty?

[PhistucK]

It is open source -

https://github.com/google/WebFundamentals/blob/master/src/content/en/fundamentals/primers/payment-request/index.markdown

https://github.com/Google/WebFundamentals/issues/new?title=[EN]%20Feedback%20for:%20/web/fundamentals/primers/payment-request/?hl=en

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Rouslan Solomakhin]

On Monday, September 19, 2016 at 12:04:38 PM UTC+1, Philip Jägenstedt wrote:

I'm also curious if there are any other attributes on PaymentAddress which are always empty?

Nope. 

[Philip Jägenstedt]

Excellent! Any thoughts on the ideal number of deprecation milestones?

[Rouslan Solomakhin]

Merchants are in holiday freeze now, so it would be best to avoid such a breaking change until January. Let's start warning about deprecation now (in console log), but actually remove it in January, after the shopping season.

[Philip Jägenstedt]

M56 will reach stable at the end of January, does that seem OK, or would it be best if it stays in dev/beta as well until January?

If merchants are extra risk averse now it also seems important that the deprecation message answer the question "is our stuff going to break" as plainly as possible, highlighting that it currently always returns the empty string, and that not using it is the only action required.

[Rouslan Solomakhin]

M56 sounds OK.

[Chris Harrelson]

Ok. LGTM1. It would be nice to merge a deprecation to M53 also.

In addition, please add UseCounters for the overall PaymentRequest API so that in the future we'll have data in hand to make decisions.

M56 sounds OK.

[Philip Jägenstedt]

OK, LGTM1 to deprecate now and remove in M56.

[TAMURA, Kent]

LGTM3

--

TAMURA Kent
Software Engineer, Google

[Rouslan Solomakhin]

M56 is here. I am starting the removal of the careOf field. Use counters show 3 uses of careOf in the last 28 days. Do we need to remove the UseCounter and the histogram as well?

[Philip Jägenstedt]

You can remove the entry from UseCounter.h when it's unused. But leave it in histograms.xml, since it may keep getting hits for a long time after removal. (I've never tried removing it, not sure what, if anything, would break.)