Open
Bug 1501162
Opened 6 years ago
Updated 2 years ago
shippingaddresschange redaction isn't compatible with jcrew.com
Categories
(Core :: DOM: Web Payments, enhancement, P2)
Core
DOM: Web Payments
Tracking
()
NEW
People
(Reporter: MattN, Unassigned)
References
()
Details
(Keywords: site-compat, Whiteboard: [webpayments-reserve])
function isAddressValid(a) {
var d = globalObj.content.countryContext.toUpperCase(), // "US"
c = 0 === a.recipient.length,
b = a.country.toUpperCase(),
e = 0 === a.postalCode.length,
g = 0 === a.city.length;
a = 0 === a.region.length;
return c || 0 === b.length || e || g || a || b !== d ? !1 : !0
}
Since we redact the `recipient`, `isAddressValid` always returns `false` and therefore no shipping options are provided.
Does Webkit also redact the `recipient`? If so, should we reach out to j.crew to see if they can change this to not require the full address until the PaymentResponse is received?
Perhaps we can put the redaction behind a pref to ease user testing and in case it's not web compatible to ship.
Reporter | ||
Comment 1•6 years ago
|
||
Also, since we no longer select the shipping address by default, maybe we can disable redaction?
Comment 2•6 years ago
|
||
Eden, how would you gauge this bug's priority?
Flags: needinfo?(echuang)
Priority: -- → P3
Updated•6 years ago
|
Whiteboard: [webpayments] [triage] → [webpayments-reserve]
Reporter | ||
Comment 3•6 years ago
|
||
Note: Shopify.com also doesn't work with the redaction but I didn't look at which fields they require.
Comment 4•6 years ago
|
||
We obviously can't add the recipient:( I'll ask Andy what Apple does, but very much doubt they add recipient, given they redact everything else.
Comment 5•6 years ago
|
||
Flags: needinfo?(echuang)
Priority: P3 → P2
Comment 6•6 years ago
|
||
(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #1)
> Also, since we no longer select the shipping address by default, maybe we
> can disable redaction?
I feel a somewhat strongly that we continue to redact until the user hits Pay. There is no reason for the merchant to get that information early - and it's surprising that so much would be shared with the merchant prior to someone committing to buy.
We've reached out to other relevant parties for feedback - so let's sit on this for a little bit till we get a bit more info.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•