View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010924 | Taler | wallet (WebExtension) | public | 2026-01-27 08:36 | 2026-01-28 16:17 |
| Reporter | Tungmar | Assigned To | Florian Dold | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Platform | Browser Vivaldi | OS | Linux | ||
| Product Version | 1.3 | ||||
| Target Version | 1.5 | ||||
| Summary | 0010924: Sending does not show the QR Code | ||||
| Description | When sending to an other wallet, the transaction is created but on the confirming page no QR-Code or other mans to forward it to an other device is shown. When opening the transaction again from the list, the QR-Code is there and the transaction can be completed. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| related to | 0010936 | confirmed | create a flag to initialize wallet with sim slow-server-response |
|
|
> When sending to an other wallet, the transaction is created but on the confirming page no QR-Code or other mans to forward it to an other device is shown. This is OK, the transaction (creating the transfer) needs to complete in order to show the code > When opening the transaction again from the list, the QR-Code is there Yes, It has been completed. Could it be possible that just it was slow and completed while you were on the balance list? Does this easy to reproduce and happens constantly? You can try open a new tab to show the balance list and go to the TX detail if there is a problem the first one will keep with the old state (transaction pending) and the new one you will see the transaction completed (with the QR) > and the transaction can be completed. The transaction is already completed if the QR is shown. Maybe you meant a new transaction in other wallet can be created and completed or "the QR can be scanned and get the money from other wallet". Correct me if I misunderstood |
|
|
There are clearly UX problems here. I'm not sure what the exact issue is, but: 1) We MUST show the QR code immediately when the user initiates the P2P payment, receive or send. AFAIK some earlier versions required you to push a button first, which is IMO bad. 2) When the transaction is completed we indeed MUST NOT show the QR code anymore, but then we MUST also say that it is completed, and not -- like in the screenshot -- claim that it is still pending. Now, the formulation in the screenshot is a bit odd, it says "pending to complete" -- that doesn't make sense in English. Either it is pending, or it is complete. Now, if the recipient scanned the QR code and we are merely "finishing" it (like getting change), then the formulation should be something like "The transaction is finishing." or maybe "The wallet is finalizing the transaction." -- now, this should basically be instant, so if a user could do a screenshot of that, I wonder if we *also* have a performance problem. |
|
|
I'm going to take this issue to 1) check if we can show the QR earlier, we had this discussion before and AFAIK is shown as soon the exchange replies the http request (it can be shown before because the wallet knows the ID but is useless and it may fail in the other end) so this is the earliest 2) Fix the "pending to complete" > if the recipient scanned the QR code This is not the case, the pending state we see in the screenshot is because the transaction "create purse" is pending. For what I read from the user report > the QR-Code is there and the transaction can be completed. After the QR is shown, the recipient was able to scan and complete the second transaction. |
|
|
The QR is shown instantly AFTER the wallet-core triggers the event `NotificationType.TransactionStateTransition` which refresh the screen with the QR. So the delay the user is reporting is between confirming the transfer and before receiving that notification. Text changed to "This transaction is pending." and remains until the recipient receives the money. |
|
|
It would be nice if we can get the user confirmation that the delay was between the creation of the transfer and the generation of the QR and NOT between the QR scanning from the recipient as @cg suggested. Nota that we don't have a intermediate state while the recipient scanned the QR code and accepted. https://docs.taler.net/design-documents/037-wallet-transactions-lifecycle.html#transaction-type-peer-push-debit So, more technically: * The screenshot is when the tx was in `pending(purse-create)` * The user went to balance list and back and saw the tx in state `pending(ready)` with QR code * After complete the tx transition to `[poll-success] => done` where the TX is in final state (instantly) The delay was between 1 and 2. And as far as I can see there is no issue with missing notifications from wallet-core to UI. Unless the user could reproduce this consistently. |
|
|
I tested it several times now. It some times really shows a the QR-Code after about 1/2 seconds, but some times not. I could not figure out in what cases it is not shown. |
|
|
We should only show the QR code after it is sure to 'work', so after the response from wallet-core. Until then, we probably should show some text like "Generating payment request...". Furthermore, if wallet-core fails to get an answer from the exchange in a timely fashion (say 1s?) we should probably indicate some transient error ("Waiting for response from server..."), show an explicit "retry now" (reload-symbol?) button and most importantly do render errors if wallet-core communicates any (like: DNS failure, TLS handshake failure, etc.) -- and auto-retry every say 30s while the dialog is open (and of course clear the transient errors upon success). |
|
|
Florian should check if there is more here that wallet-core can/should do to report transient issues/progress. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-01-27 08:36 | Tungmar | New Issue | |
| 2026-01-27 08:36 | Tungmar | File Added: Screenshot_20260127_083231.png | |
| 2026-01-27 09:35 | Christian Grothoff | Assigned To | => sebasjm |
| 2026-01-27 09:35 | Christian Grothoff | Status | new => assigned |
| 2026-01-27 09:36 | Christian Grothoff | Priority | normal => urgent |
| 2026-01-27 09:36 | Christian Grothoff | Target Version | => 1.4 |
| 2026-01-27 15:38 | sebasjm | Note Added: 0027389 | |
| 2026-01-27 15:38 | sebasjm | Status | assigned => feedback |
| 2026-01-27 15:39 | sebasjm | Priority | urgent => low |
| 2026-01-27 15:56 | Christian Grothoff | Note Added: 0027390 | |
| 2026-01-27 16:05 | sebasjm | Status | feedback => confirmed |
| 2026-01-27 16:05 | sebasjm | Priority | low => normal |
| 2026-01-27 16:10 | sebasjm | Note Added: 0027391 | |
| 2026-01-27 20:04 | sebasjm | Note Added: 0027397 | |
| 2026-01-27 20:12 | sebasjm | Status | confirmed => feedback |
| 2026-01-27 20:12 | sebasjm | Note Added: 0027398 | |
| 2026-01-27 20:12 | sebasjm | Assigned To | sebasjm => |
| 2026-01-28 08:50 | Tungmar | Note Added: 0027403 | |
| 2026-01-28 08:50 | Tungmar | Status | feedback => new |
| 2026-01-28 08:57 | Christian Grothoff | Note Added: 0027405 | |
| 2026-01-28 08:58 | Christian Grothoff | Note Added: 0027407 | |
| 2026-01-28 11:42 | Christian Grothoff | Assigned To | => Florian Dold |
| 2026-01-28 11:42 | Christian Grothoff | Status | new => assigned |
| 2026-01-28 11:42 | Christian Grothoff | Target Version | 1.4 => 1.5 |
| 2026-01-28 16:17 | sebasjm | Relationship added | related to 0010936 |
