Tom, let me know if you want me to follow up with any details here.
Assignee: nobody → ferjmoreno
Should this be a P1 blocker?
blocking-basecamp: --- → ?
Created attachment 664402 [details] [diff] [review] v1 This patch skips the old payment provider confirmation (now selection) screen unless the payment request contains more than one JWT (with different 'typ' values). In that case, the platform allows the user to choose the payment provider that she prefers. The only significant change is in dom/payment/Payment.jsm, where the condition has been added. The other changes are for renaming 'confirmation' to 'selection'. Once this lands, the Gaia side will also require some modifications.
(In reply to Fernando Jiménez Moreno [:ferjm] from comment #2) > Should this be a P1 blocker? I say yes because it is required by UX for launching payments for basecamp. Maria S (mushi) can provide details about the UX requirement.
So, I'm not a big fan of having this skipping functionality in the back-end. Is there anything that prevents the content side (eg Gaia) to return the only choice available if there's only one?
(In reply to Fabrice Desré [:fabrice] from comment #5) > So, I'm not a big fan of having this skipping functionality in the back-end. > Is there anything that prevents the content side (eg Gaia) to return the > only choice available if there's only one? Yes, we could do that on the content side, but I would like to understand your reasons to prefer this option before :) IMHO it would be better to avoid any mozChromeEvent <-> mozContentEvent dance if possible. If your concern is about doing this in the common part (dom/payment/Payment.jsm) we can still do it in the B2G glue, so the check is only done in B2G (just in case we finally implement mozPay for other platforms). Thanks Fabrice!
My main reason is that this is a UX decision, so I'd rather have the code as close to UI as possible. This is what we do for web activities, and for install/updates API we also had to let the UI drive the process because of complex UX requirements. In general, keep the backend dumb and secure, and let the front-end drive it. I'm not sure moving that in the b2g glue is good enough either. mozChromeEvents are not *that* bad anyway...
(In reply to Fabrice Desré [:fabrice] from comment #7) > My main reason is that this is a UX decision, so I'd rather have the code as > close to UI as possible. This is what we do for web activities, and for > install/updates API we also had to let the UI drive the process because of > complex UX requirements. In general, keep the backend dumb and secure, and > let the front-end drive it. > > I'm not sure moving that in the b2g glue is good enough either. > mozChromeEvents are not *that* bad anyway... Ok. I still think that saving any extra event flow is worth the platform modification :). Anyway, I've just sent this PR https://github.com/mozilla-b2g/gaia/pull/5235 with the required modification. Should I close this as WONTFIX?
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
Fabrice, could you take a look at the Gaia PR, please :)? I am not sure if you notice the github notifications.
Created attachment 667396 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/5235 Pointer to Github pull-request
Attachment #667396 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.