Clicking on Cancel shows an error message and user is stuck in the Trusted UI

RESOLVED FIXED

Status

P1
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: krupa.mozbugs, Unassigned)

Tracking

({qawanted})

qawanted
Points:
---
Dependency tree / graph

Details

(Whiteboard: r=?)

(Reporter)

Description

6 years ago
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.
This might be a regression because of Bug 828076
Assignee: nobody → ferjmoreno
blocking-basecamp: --- → ?
Whiteboard: regression
(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

6 years ago
Component: Payments/Refunds → Gaia::System
Product: Marketplace → Boot2Gecko
Version: 1.0 → unspecified

Updated

6 years ago
Keywords: regression
Whiteboard: regression

Updated

6 years ago
Blocks: 828076
blocking-basecamp: ? → +
Priority: -- → P2
Target Milestone: --- → B2G C4 (2jan on)

Comment 3

6 years ago
How are we doing here?
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.
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:"
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

6 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

6 years ago
Assignee: ferjmoreno → nobody
No longer blocks: 828076
Keywords: regression
It might also be a problem of nested trusted UIs. I'll keep on trying to reproduce it.
Assignee: nobody → ferjmoreno
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)
Flags: needinfo?(kumar.mcmillan)
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.
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
(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

6 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)
(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?
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: ? → ---
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

Updated

6 years ago
Depends on: 830036

Updated

6 years ago
No longer depends on: 829170
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.

Updated

6 years ago
Keywords: qawanted
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
(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.
krupa: are there steps to reproduce this?  I hear it's intermittent
Depends on: 828513
(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.
Whiteboard: r=?
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.
(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.
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

6 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

6 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
(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

6 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.
thanks everyone
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.