Closed Bug 959230 Opened 6 years ago Closed 6 years ago
Failed/payment Success not available in webpay
Looking at bug 924693 payment callbacks should be implemented, however, following the STR in bug 920822 the tab doesn't close and the following is visible in the console over and over: E/GeckoConsole(23689): [pay] waiting for paymentFailed to appear in scope Which is coming from https://github.com/mozilla/webpay/blob/master/media/js/pay/cancel.js#L16 This suggests that there's been a regression as bug 924693 looks to have been verified and confirmed working. I'm using nightly 29.0a1 on Samsung Galaxy s3 with android 4.3 (Stock). Detailed STR/Test case: * Get android setup as per https://wiki.mozilla.org/Marketplace/PaymentAndroid * Go to marketplace stage http://marketplace.allizom.org/ * Find a paid app and try and buy it. (hint searching ':paid' will help get to paid apps more quickly if none are featured). * Once on webpay (Pin create/entry screen) hit cancel. What should happen: * Webpay tab is closed. What happens: * Throbber is shown and "[pay] waiting for paymentFailed to appear in scope" is continuously logged due to the lack of paymentFailed.
Apparently on success the tab's not closing either which suggest paymentSuccess isn't there either.
Summary: paymentFailed not available in webpay → paymentFailed/paymentSuccess not available in webpay
Can you test this again when bug 921112 hits central? I tested yesterday with it on my S3 and it seemed to work.
Stuart, could you re-test this?
Still failing for me with Firefox Android 29.0a1 (2014-01-16)
:lucasr is there anything else I need to know to be able to test this or is it just that the change I need isn't there yet?
(In reply to Stuart Colville [:scolville] from comment #5) > :lucasr is there anything else I need to know to be able to test this or is > it just that the change I need isn't there yet? wesj is probably the best person to answer this question :-)
Flags: needinfo?(lucasr.at.mozilla) → needinfo?(wjohnston)
Nope. I can reproduce it too. Not sure what's up. I wonder if, because you're pulling mozPaymentProvider off of this cli object, it doesn't matter that you're polling for it. i.e. if it wasn't defined when the cli object was created it will never be defined. We can try moving DOMWindowOpened for attaching these methods (instead of DOMContentLoaded) like b2g does.
This matches better what b2g does: http://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/payment.js#385 Need a test for this stuff...
Attachment #8363164 - Flags: review?(mark.finkle)
I should say, fixes the issue for me
Comment on attachment 8363164 [details] [diff] [review] Patch v1 I like this better too
Attachment #8363164 - Flags: review?(mark.finkle) → review+
Payments aren't turned on for release (they're turned on, but we have no provider). Not tracking
tracking-fennec: ? → ---
This got an r+ I think, is this good to merge?
Apologies. I thought I landed this for you. in: https://hg.mozilla.org/integration/fx-team/rev/21ac04e55976
Comment on attachment 8363164 [details] [diff] [review] Patch v1 [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 959230 User impact if declined: Payment callbacks are not there if you request them too early in page load Testing completed (on m-c, etc.): Landed on mc today. Tested on the dev server Risk to taking this patch (and alternatives if risky): Very low risk. Just moving some events. Same as other dom apis like this. matches b2g now. String or IDL/UUID changes made by this patch: none
Assignee: nobody → wjohnston
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 30
You need to log in before you can comment on or make changes to this bug.