Closed Bug 833955 Opened 11 years ago Closed 11 years ago

Don't reload the details page in marketplace app if the login happened mid-purchase

Categories

(Marketplace Graveyard :: Payments/Refunds, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: krupa.mozbugs, Assigned: mhanratty)

References

Details

(Whiteboard: u=dev p=3)

steps to reproduce:
1. Tester is not logged in
2. In marketplace-dev app, navigate to the details page for a paid app
3. Click on the purchase button
4. IdentityFlow opens in the trustedUI
5. Log in with valid credentials

expected behavior:
After successful login, the paymentFlow opens in the trustedUI without getting back to the marketplace app

observed behavior:
After successful login, the focus returns to the marketplace app for a few seconds after which the trustedUI opens.
Priority: -- → P3
Target Milestone: --- → 2013-01-31
Whiteboard: u=dev p=
Version: 1.0 → 1.1
I'd like to do this, but I'm not sure how without introducing bizarre effects into the consumer UI.
Target Milestone: 2013-01-31 → 2013-02-07
For now, the reload is non-negotiable.

Shall I:

a) reload before purchase
b) reload after a purchase resolves (is successful or cancels)

krupa?
Flags: needinfo?(krupa.mozbugs)
(In reply to Potch [:potch] from comment #2)
> For now, the reload is non-negotiable.
> 
> Shall I:
> 
> a) reload before purchase
> b) reload after a purchase resolves (is successful or cancels)
> 
> krupa?

I pick b)

What happens if the user cancels the purchase? we should still reload and have them be logged in.
Flags: needinfo?(krupa.mozbugs)
Version: 1.1 → 1.2
doing this sucks a lot- I'm stuck on generating a valid csrf token for the prepareNavPay and other subsequent requests.
Target Milestone: 2013-02-07 → 2013-02-28
Whiteboard: u=dev p= → u=dev p=3
Target Milestone: 2013-02-28 → 2013-03-14
This will be unnecessary in Fireplace, and overly complicated to fix in zamboni. Should I still push on the solution?
no, fireplace is where we are going. Assuming "unnecessary in Fireplace" means this works on fireplace+desktop as well
All right then!
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
This is not fixed in Fireplace and basta thinks it cannot be avoided. Cc'ing basta so he can expound more on this here.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Let's talk about what's going on here:

On old marketplace:
- Login was synchronous, so a full reload had to happen
- After the reload, we have to then do a POST to get the JWT
- After the POST, we can trigger mozPay

In Fireplace:
- Login is async, so we POST our assertion to the API and get back a user token
- We POST our user token to the API to get a JWT
- After the POST, we can trigger mozPay

Some things that should be made clear:
- We can't go *directly* from Persona to the trusted UI. Something needs to say, "now that you're done with this, go do that," and that's the Marketplace. The Marketplace can't issue those kinds of instructions if it's not in focus.
- The delay between login and mozPay is shorter in Fireplace (by a lot) since login is async.
- There isn't a full page reload in Fireplace since login is async.

So the key here is to minimize the time between the close of Persona and the triggering of the trusted UI.

Some things we could do:

1. Increase the performance of the API
2. Create an API endpoint that both logs you in and fetches a JWT (please let's not do this)
3. Show an overlay so that the user isn't simply sitting on the page wondering what happened while we're doing API calls with our pants down.

Those are, to the best of my understanding, the only three things we can do to resolve this problem. #3 is the only item we can reasonably take action on, and that will require design work.

Feel free to assign to UX or WONTFIX; I'll leave that call up to someone else.
Flags: affects-moss+
Flags: affects-tricycle+
Flags: affects-seville+
Flags: affects-seahorse+
Flags: affects-durango+
Assignee: thepotch → mhanratty
Target Milestone: 2013-03-14 → ---
Version: 1.2 → 1.3
Version: 1.3 → 1.4
Maureen, do you think this is worth doing or should we won't fix?
Flags: needinfo?(mhanratty)
Yes, directly after login the Trusted UI should open up. It should not go back to the app details screen as it is a unexpected and undesired step in the purchase flow.
Flags: needinfo?(mhanratty)
As I explained in comment #9, I don't believe this is technically possible.
Maureen, assuming it can't happen, can we go for the next best thing which is showing a message?
Flags: needinfo?(mhanratty)
I don't think showing a message is going to help things. Let's just leave as a WONTFIX.
Flags: needinfo?(mhanratty)
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.