Closed
Bug 829176
Opened 12 years ago
Closed 12 years ago
Clicking on Cancel shows an error message and user is stuck in the Trusted UI
Categories
(Marketplace Graveyard :: Payments/Refunds, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: krupa.mozbugs, Unassigned)
References
Details
(Keywords: qawanted, Whiteboard: r=?)
steps to reproduce:
1. Log into marketplace-dev on your unagi phone
2. Search for 'Private Yacht' on your phone.
3. Click on Purchase
4. Set up your PIN and confirm it
5. Send SMS screen loads
6. Click the Cancel button
expected behavior:
On clicking the cancel button, the trusted UI closes and the user returns to the app details page in marketplace-dev
observed behavior:
We show the error message "There was an error processing your payment" and user cannot dismiss the trustedUI by clicking on the 'x' button.
Comment 1•12 years ago
|
||
This might be a regression because of Bug 828076
Assignee: nobody → ferjmoreno
blocking-basecamp: --- → ?
Whiteboard: regression
Comment 2•12 years ago
|
||
(In reply to Fernando Jiménez Moreno [:ferjm] from comment #1)
> This might be a regression because of Bug 828076
I was afraid of this. Is it that you do need the close() function to trigger the 'cancel' event after all? Let's work through this on IRC.
Updated•12 years ago
|
Component: Payments/Refunds → Gaia::System
Product: Marketplace → Boot2Gecko
Version: 1.0 → unspecified
Updated•12 years ago
|
Keywords: regression
Whiteboard: regression
Updated•12 years ago
|
blocking-basecamp: ? → +
Priority: -- → P2
Target Milestone: --- → B2G C4 (2jan on)
Comment 3•12 years ago
|
||
How are we doing here?
Comment 4•12 years ago
|
||
I've just checked that this works with a mock payment provider like http://people.mozilla.com/~kmcmillan/pay-provider.html .
I'm trying to reproduce it...
I can't test with the marketplace-dev cause it is not working for me. I've reverted https://github.com/mozilla-b2g/gaia/commit/59e82587725ce060a228f24d4ba1746b6a82c3a2 so I can have the marketplace-dev again in Gaia. But I am not able to login with my persona account (after entering email and password, clicking 'sign in' does nothing) so I can't trigger the buy flow for the 'Private Yacht' app as mentioned in comment 0.
Comment 5•12 years ago
|
||
I was finally able to login in the marketplace-dev with Persona, but clikcin in the '$0.99' button of 'Private Yacht' app does nothing and throws this error in the logcat:
"E/GeckoConsole( 452): Content JS LOG at https://marketplace-dev-cdn.allizom.org/media/js/mkt/consumer-min.js?build=aef9d41:16 in anonymous: Error code:"
Comment 6•12 years ago
|
||
If this works with a trusted UI with the mock payment provider then I've got a hunch that this is a marketplace bug. Renom and moving back to marketplace.
Updated•12 years ago
|
blocking-basecamp: + → ---
Component: Gaia::System → Payments/Refunds
Priority: P2 → --
Product: Boot2Gecko → Marketplace
Target Milestone: B2G C4 (2jan on) → ---
Version: unspecified → 1.0
Updated•12 years ago
|
Comment 7•12 years ago
|
||
It might also be a problem of nested trusted UIs. I'll keep on trying to reproduce it.
Assignee: nobody → ferjmoreno
Comment 8•12 years ago
|
||
I was finally able to trigger a purchase flow from the marketplace-dev, but now I am stacked at the 'Create payment PIN' and/or 'Enter payment PIN' screens. These are the steps I followed:
- After clicking in the '$0.99' button, the trusted UI is opened and the 'Create your PIN' screen is shown.
- Clicking the 'Cancel' button in the 'Create your PIN' screen does nothing. No logcat output either.
- I tried creating a payment PIN, but after entering the PIN, the screen just refresh itself. The logcat says 'I/Gecko ( 646): nsDOMIdentity (17): init was called from https://marketplace-dev.allizom.org/mozpay/pin/verify'.
- Clicking the 'X' button closes the trusted UI.
- Clicking again in the '$0.99' button reopens the payment flow, this time with the 'Enter payment PIN' screen.
- Entering the PIN entered in the previous screen results in an 'Incorrect PIN' message and the PIN form is shown again.
- Clicking in the 'Forgot PIN' button shows 'Something went wrong! There was an error processing that request.' within the trusted UI, which is not closed.
- Clicking the 'X' button closes the payment flow.
Kumar, Krupa, any idea?
Flags: needinfo?(krupa.mozbugs)
Updated•12 years ago
|
Flags: needinfo?(kumar.mcmillan)
Comment 9•12 years ago
|
||
Fernando - Is it possible that the fact that the trusted UI ended on top of the SMS app during this flow may cause the X button to not work? So the other bug fixing that issue could resolve this problem?
I think I've that issue happen before when the trusted UI ended up on top of an app.
Comment 10•12 years ago
|
||
Actually I just confirmed comment 9 by reproducing the web activity bug while the trusted UI ends up on top of the settings app.
QAWanted - Krupa, Can you retest with that web activity bug fixed?
Flags: needinfo?(kumar.mcmillan)
Keywords: qawanted
Comment 11•12 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #9)
> Fernando - Is it possible that the fact that the trusted UI ended on top of
> the SMS app during this flow may cause the X button to not work? So the
> other bug fixing that issue could resolve this problem?
>
> I think I've that issue happen before when the trusted UI ended up on top of
> an app.
Might be.
I've just checked that nested trusted UIs work as expected.
Reporter | ||
Comment 12•12 years ago
|
||
I'm on today's build which I got from https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-unagi/latest/
I can still reproduce this issue.
blocking-basecamp: --- → ?
Flags: needinfo?(krupa.mozbugs)
Comment 13•12 years ago
|
||
(In reply to krupa raj 82[:krupa] from comment #12)
> I'm on today's build which I got from
> https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-
> unagi/latest/
>
> I can still reproduce this issue.
I haven't tried. But was gaia updated too?
Comment 14•12 years ago
|
||
krupa mentioned in IRC after her build the test case I referenced to see if the patch was included then worked. So let's try again.
blocking-basecamp: ? → ---
Comment 15•12 years ago
|
||
Okay...I just grabbed a recent nightly build and I still reproduce the bug with the settings activity test case. Let me mark this a dependency on that bug.
I do know there were some nasty github problems that happened yesterday that may have delayed getting the patch included in the build. So maybe we need to wait a bit. I've put needsinfo on bug 829170 on Alberto to see if he knows.
Assignee: ferjmoreno → nobody
Depends on: 829170
Comment 16•12 years ago
|
||
I dug into this with a more recent build - I confirm Krupa's findings.
See bug 830036 for a followup. Let's try again after that's fixed.
Comment 17•12 years ago
|
||
Sorry, I am late to the bug here. Please note that according to the STR, this exact Cancel button is hosted by the Bango flow. I do not know that they are calling paymentFailed() from this button click. I will check with them. It could be as simple as fixing their click handler. It sounds like their Cancel button is actually triggering our error flow, which is not yet finished per bug 828513
However, clicking the X should also do the right thing here and it's not.
Priority: -- → P1
Comment 18•12 years ago
|
||
(In reply to Kumar McMillan [:kumar] from comment #17)
> Sorry, I am late to the bug here. Please note that according to the STR,
> this exact Cancel button is hosted by the Bango flow. I do not know that
> they are calling paymentFailed() from this button click. I will check with
> them. It could be as simple as fixing their click handler. It sounds like
> their Cancel button is actually triggering our error flow, which is not yet
> finished per bug 828513
>
> However, clicking the X should also do the right thing here and it's not.
Right. That's bug 830056.
Comment 19•12 years ago
|
||
krupa: are there steps to reproduce this? I hear it's intermittent
Depends on: 828513
Comment 20•12 years ago
|
||
(In reply to Wil Clouser [:clouserw] from comment #19)
> krupa: are there steps to reproduce this? I hear it's intermittent
I'd wait for bug 830036 to land first before retesting. I get the feeling this bug is a symptom of that bug.
Updated•12 years ago
|
Whiteboard: r=?
Comment 21•12 years ago
|
||
I confirmed that Bango's cancel button is doing the right thing. We need to handle it better on the Mozilla side, see bug 830422. This is a separate issue from clicking the X in the window.
Comment 22•12 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #18)
> > However, clicking the X should also do the right thing here and it's not.
>
> Right. That's bug 830056.
Can you summarize how @font-face scoping would prevent one from clicking an anchor? I don't understand.
Comment 23•12 years ago
|
||
Okay. Apparently the 1/15 build finally has the fix to that one web activity trusted UI issue. Can you retest now?
Keywords: qawanted
Reporter | ||
Comment 24•12 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #23)
> Okay. Apparently the 1/15 build finally has the fix to that one web activity
> trusted UI issue. Can you retest now?
I can reproduce the behavior from comment 0 on my unagi build from 01/16. I cannot test this behavior on today's build since marketplace has login issues.
Reporter | ||
Comment 25•12 years ago
|
||
(In reply to krupa raj 82[:krupa] from comment #24)
> (In reply to Jason Smith [:jsmith] from comment #23)
> > Okay. Apparently the 1/15 build finally has the fix to that one web activity
> > trusted UI issue. Can you retest now?
>
> I can reproduce the behavior from comment 0 on my unagi build from 01/16. I
> cannot test this behavior on today's build since marketplace has login
> issues.
The login issue for marketplace is being tracked at bug 831973
Comment 26•12 years ago
|
||
(In reply to krupa raj 82[:krupa] from comment #24)
> (In reply to Jason Smith [:jsmith] from comment #23)
> > Okay. Apparently the 1/15 build finally has the fix to that one web activity
> > trusted UI issue. Can you retest now?
>
> I can reproduce the behavior from comment 0 on my unagi build from 01/16. I
> cannot test this behavior on today's build since marketplace has login
> issues.
I'm going have to see this directly then. I don't understand how this trusted UI piece of the flow isn't working based on the given info. Unless this only failing on the webpay portion.
Reporter | ||
Comment 27•12 years ago
|
||
(In reply to krupa raj 82[:krupa] from comment #24)
> (In reply to Jason Smith [:jsmith] from comment #23)
> > Okay. Apparently the 1/15 build finally has the fix to that one web activity
> > trusted UI issue. Can you retest now?
>
> I can reproduce the behavior from comment 0 on my unagi build from 01/16. I
> cannot test this behavior on today's build since marketplace has login
> issues.
Okay, I tried the latest build and now i can close the error screen and return to marketplace app. Looks like we can close this bug. Thanks all.
Comment 28•12 years ago
|
||
thanks everyone
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•