After cancelling the installation of an app the user is not able to install the app

VERIFIED FIXED in 2013-07-11

Status

P2
normal
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: vikas.nanda, Assigned: basta)

Tracking

2013-07-11
x86_64
Windows 7
Points:
---

Details

Attachments

(5 attachments)

(Reporter)

Description

6 years ago
Created attachment 762173 [details]
The user is not able to install the application after they have cancelled

Steps to reproduce:

1. Start the application. 
2. Search for a paid app. 
3. Press the price button
4. Enter the pin
5. Confirm the payment. 
6. On the installation screen press cancel. 
7. Notice that the user is not redirected to the app details page
8. If the user searches the app or navigates to my apps they will not be able to install the application. 

Expected behavior:

The user should be able to install the application after they have cancelled installation. 

Observed behavior: 

The user is not able to install the application.
(Reporter)

Comment 1

6 years ago
Created attachment 762177 [details]
The user is not able to install the application after they have cancelled
(Assignee)

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 834954

Comment 3

5 years ago
Hey Matt, I am not sure that this is a dupe of bug 834956 . The button state is the correct one(Install), but we are receiving "Error while communicating with server. Please try again later" message when we are trying to install an already purchased app.

I will attach a new set of logs.
This is reproducible for both Poland and Spain so it could be a blocker for payments push for Spain.

Please note that sometimes same error is displayed immediatelly after purchase when installation confirmation page should be automatically displayed.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 4

5 years ago
Created attachment 770169 [details]
Logs 07/02
(Assignee)

Comment 5

5 years ago
Hmm, this might be related to the receipt signing nonsense that's been going on lately.

Can you reproduce the issue on dev?

Also, in the future please use the "Submit logs" functionality instead of logcat. The results are much easier to read and provide much more useful information.

Comment 6

5 years ago
Yes , I can reproduce it on -dev and now you have logs as you requested above:
ID : d0f0c
Priority: -- → P2

Comment 7

5 years ago
I don't think it has anything to do with the receipt nonsense and to do with starting the payment flow once its already been paid for. 

1074582776[40304160]: http request [
1074582776[40304160]:   POST /api/v1/webpay/prepare
..
26687144[40304470]: http response [
26687144[40304470]:   HTTP/1.1 403 FORBIDDEN

If an app has already been purchased doing it again will cause a 403.

Updated

5 years ago
Component: General → Consumer Pages

Comment 8

5 years ago
After confirming the payment if the user cancels the install and tries to install the app again it will not install and the error message "Error while communication with the server. Try again later" is displayed.
(Assignee)

Comment 9

5 years ago
I added a bunch of logging that adds a speculative fix for a timeout issue:

https://github.com/mozilla/fireplace/commit/94a05a61fb65b91b74d9f7b0a5da51aa3483dd40

Can someone please try reproducing this again and submit their logs?

https://github.com/mozilla/fireplace/tree/master/ashes#submitting-logs

Comment 10

5 years ago
Upon trying to reinstall a previously purchased app I hit a 403 @ POST /api/v1/webpay/prepare/?_user=krupa.mozbugs%40gmail.com%2C364ff8700311ff35a4a5a8c3bb0d7924c20d0bcd4e3329cc0052a9209559801caf49ddcbd0505f3d35243c7ef429d0e751fb71957f7c248e7d8f6098d19be6fd%2C7e40f1a17a8245b0b900f483d453da12&carrier=telefonica&dev=firefoxos&device=firefoxos&lang=es&pro=fbdf7fdc.32.1&region=es)

ashes: 5469e

Comment 11

5 years ago
latest ashes: 18804
(Assignee)

Comment 12

5 years ago
The 403 issue is a separate issue, I think. Once those ones are cleaned up, this should be easier to debug and test.

In the interim, I think this might be fixed. All the timeouts/intervals are being cleaned up properly now. I'll update this bug with details and harass Krupa to test when the API is un-borked.
Also see bug 882740, which fixes things.
To fix the 403 status code: that's bug 891000. Everything's okay with the POST though.
Assignee: nobody → mattbasta
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2013-07-11
(Reporter)

Comment 14

5 years ago
Created attachment 772662 [details]
screenshot
(Reporter)

Comment 15

5 years ago
Created attachment 772663 [details]
ezboot log
(Reporter)

Comment 16

5 years ago
Issue still occurs, new screenshot and log added.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 17

5 years ago
Issue no longer occurs, thanks
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED

Comment 18

5 years ago
reinstall of purchased apps works fine now. There is an issue with My Apps page which is being tracked elsewhere.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.