+++ This bug was initially created as a clone of Bug #807122 +++ STR using http://people.mozilla.com/~kmcmillan/pay.html on B2G [1]: 1. click 'pay' 2. payment ui opens in trusty ui 3. click login 4. persona login opens in trusty ui. When it closes you are back to the payment Trusty UI. 5. click Close Window in the payment Trusty UI to return to pay.html The close window button will call paymentSuccess(). This is a global defined by the payment specific Trusty UI. What happens here is that the identity Trusty UI is overwriting this global somehow. If you try the STR above but omit step #3 then you will see that paymentSuccess() is still defined. [1] To see this in action you need to modify some prefs. Ask jedp, zaach, or kumar

The good news is that the patch in bug 807122 is otherwise working! Target has shifted to this since it blocks the payment flow from fully working.

One note (cause we have careful about bug cloning) - I'd rather nom first, and have a driver review for basecamp stuff. I do think it blocks, but I want Ben to sign off on it, as he's the owner of identity. Priorities-wise, I can explain on the 11am call how they work, but in short: Priorities are set with a basecamp nomination based on the chart below: - P1: Smoke test blocker, required feature, etc - P2: Security bug, really bad crash, etc - P3: Major Functionality and Usability bugs It's possible it's a P1 or P3 nomination to block depending on the following details: - What's the impact if paymentSuccess is called through the identity dialog?

(In reply to Jason Smith [:jsmith] from comment #2) > - What's the impact if paymentSuccess is called through the identity dialog? You mean what is the impact of this bug where paymentSuccess cannot be called? The impact is no one would ever be able to buy an app or make an in-app purchase their first time (when not logged in) since it would never complete

(In reply to Kumar McMillan [:kumar] from comment #3) > (In reply to Jason Smith [:jsmith] from comment #2) > > - What's the impact if paymentSuccess is called through the identity dialog? > > You mean what is the impact of this bug where paymentSuccess cannot be > called? > > The impact is no one would ever be able to buy an app or make an in-app > purchase their first time (when not logged in) since it would never complete No, actually I meant the opposite. This bug to my understanding is talking about the identity pop-up calling a payment success callback unexpectedly. I'm wondering what the impact of that issue is.

(In reply to Jason Smith [:jsmith] from comment #4) > No, actually I meant the opposite. This bug to my understanding is talking > about the identity pop-up calling a payment success callback unexpectedly. > I'm wondering what the impact of that issue is. That's not the bug. The nav.mozPay() trusty UI defined a global called paymentSuccess() and we need to preserve that. The identity's trusty UI is overriding that global probably because it switches the trusty UI context. We need to fix that because otherwise the end to end payment flow is broken.

(In reply to Kumar McMillan [:kumar] from comment #5) > (In reply to Jason Smith [:jsmith] from comment #4) > > No, actually I meant the opposite. This bug to my understanding is talking > > about the identity pop-up calling a payment success callback unexpectedly. > > I'm wondering what the impact of that issue is. > > That's not the bug. The nav.mozPay() trusty UI defined a global called > paymentSuccess() and we need to preserve that. The identity's trusty UI is > overriding that global probably because it switches the trusty UI context. > We need to fix that because otherwise the end to end payment flow is broken. Oh, now I understand it. Gotcha. Makes sense. In that case, that's probably a P1 blocker then.

Is this fixed? Haven't tested it myself, but other comments in IRC may be implying that this is fixed.

(In reply to Jason Smith [:jsmith] from comment #7) > Is this fixed? Haven't tested it myself, but other comments in IRC may be > implying that this is fixed. Yes, a fix for this was included in the patch for 807122.

Is this bug also related for Firefox Desktop ?

There is no payments API implementation for Firefox Desktop yet, so I guess no.