939328 - User is prompted to sign in for every purchase

Status: RESOLVED WONTFIX

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

Description

[krupa raj[:krupa]]

Nightly 28.0a1 (11-04)

steps to reproduce:
1. Load marketplace stage on Firefox mobile
2. Start the purchase of a paid app
3. Sign in using your persona address when prompted to sign up.
4. Complete the app purchase
5. Return to marketplace-stage and start a second app purchase


expected behavior:
User is already logged in and doesn't need to log in for every purchase

observed behavior:
User is prompted to sign in for every purchase

Comment 1

[Andy McKay]

Sounds like cookies from the previous "trusted ui" session are not being retained for the second invocation?

Comment 2

[Kumar McMillan [:kumar]]

Wes, this sounds more serious than bug 939270. It looks like cookies are not preserved in the mozPay() window between invocations. To rule out marketplace, a simple cookie set/read test would help deduce this.

Comment 3

[Andy McKay]

If I:

* log into the marketplace on nightly
* search for paid app, hit buy
* we reset the users account, the log is here:

https://www.dropbox.com/s/y2l0tt59l99zod4/Screenshot%202013-11-27%2016.22.44.png

Is navigator.id.logout being triggered for a reason here? This then goes on to call reset_user on the webpay server, which is a noop, but I'm guessing that logout being called is the problem. This doesn't occur on firefox os.

Comment 4

[Andy McKay]

I think mozPay is doing the right things with cookies here. I set up a simple test:

* change in about:config so that mozilla-local/payments/pay/v1/ points to http://www.agmweb.ca/files/mozpay-end.html
* go to http://www.agmweb.ca/files/mozpay.html
* note a test1 cookie is written
* click "Test", note that on the next page (which has been opened by webpay, we have the cookie)

Comment 5

[Andy McKay]

I couldn't find anything wrong with the cookie handling so far in Android. I think this is related to bug 939270 and so assigning to Kumar for further investigation.

Comment 6

[Kumar McMillan [:kumar]]

oops! The login problem was because I told Wes to put 'dom.identity.enabled = true' in our addon to flip payment prefs but that kicked in some native code. Android won't ship with that so it should be false (which fixes the login issue).

I'll leave this bug open so I can patch the addon.

Comment 7

[Kumar McMillan [:kumar]]

Hey Wes, could you pull this in and upload a new version of your super nifty addon? The testers have been using it. https://github.com/wesj/devMarketplace/pull/1

Comment 8

[Kumar McMillan [:kumar]]

Since we're still trying to crack this, Wes, you can hold off on that patch. I think it only fixed part of the problem. It fixed a login on one page but not another (our bounce page). I'm still digging into that.

Comment 9

[Kumar McMillan [:kumar]]

It looks like Persona is not handling the unverified email correctly. Not sure if it's us or them. Here's the issue: https://github.com/mozilla/persona/issues/4073

Comment 10

[Kumar McMillan [:kumar]]

deduced this to a Persona issue (maybe)

Comment 12

[Andy McKay]

This because of our use of unverified emails in the web version of persona as opposed to native. With the impending arrival of Firefox Accounts, we decided it wasn't worth trying to fix this and instead focus attention on Firefox Accounts. Unfortunately till that lands, we'll just have to live with this.