Closed Bug 1492399 Opened 3 years ago Closed 3 years ago

Original Billing Address is pre-selected after returning from the "Edit Billing Address" screen via "Back" button


(Firefox :: WebPayments UI, defect, P1)




Firefox 65
Tracking Status
firefox65 --- verified


(Reporter: tbabos, Assigned: sfoster)



(Whiteboard: [webpayments])


(2 files)

Attached video Video of the issue
[Affected versions]: 
Nightly 64.0a1 

[Affected platforms]:
Platforms: Windows 7/10 x64, Ubuntu 18.04, Mac OS 10.13

1. Set the pref dom.payments.request.enabled to "true";
2. Make sure you have several Payment Methods saved with and without Billing Address

[Steps to reproduce]:
1. Go to "" page and click on "Buy" button.
2. Select any saved Payment Method
3. Click on Edit 
4. Select a different Billing Address, keep in mind the original one
5. Click on "Edit" for the new address
6. Click on "Back"
7. Check the Billing Address

[Expected result]:
If the user selects a different option for the billing address it should remain selected even after returning from the "Edit" screen without making any updates. (return via "Back" button)

[Actual result]:
The original billing address is once again displayed in the field instead of the one that the user choose in Step [4], thus forcing the user to select once more the desired billing address. 

In case of the credit cards that did not follow the First Follow (don't have an original billing address saved) the blank option will be displayed in the field after following the above mentioned steps.
Flags: qe-verify+
This is too complicated to fix in bug 1480717 and since our user testing participant will likely only have one address the probably won't see this issue.
Priority: -- → P3
Whiteboard: [webpayments] [triage] → [webpayments-reserve]
Priority: P3 → P2
Whiteboard: [webpayments-reserve] → [webpayments]
Depends on: 1482689
In bug 1482689 I just got done ensuring that the card record's billing address guid is preferred for setting the selection in the billing address picker. Fixing this bug as described would change that, so I would like to confirm this is what we want before I look into changing it.
Flags: needinfo?(jsavory)
The user's change should be preferred and that's why we have the preserveFieldValues property.
Ok I'll look into why preserveFieldValues isn't being honored here. Clearing ni for UX.
Assignee: nobody → sfoster
Flags: needinfo?(jsavory)
Priority: P2 → P1
I see what's going on here. When we loadRecord the EditCreditCard (formHandler) is passed a preserveFieldValues flag, but this is not passed through to generateBillingOptions. That function assumes we always want to select the option with the guid matching the billingAddressGUID on the current record. 

I don't see a way to get into this position from the Preferences UI so I'll just be adding a test on the payments side to cover this change.
Pushed by
honor preserveFieldValues when generating billing address options. r=MattN
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 65
Verified as fixed on Firefox Nightly 65.0a1 (2018-11-08) on Windows 10 x 64, Windows 7 x32, Mac OS X 10.13 and on Ubuntu 16.04 x64.
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.