xrpl-labs / xaman-issue-tracker Goto Github PK
View Code? Open in Web Editor NEWBugs, improvements, suggestions & release progress (Project boards)
Home Page: https://xumm.app
Bugs, improvements, suggestions & release progress (Project boards)
Home Page: https://xumm.app
Create a pack with images and logos (for on white, dark, etc.) and create a collateral page on the website + link the docs there, eg. for press and if people want to implement on their site and use a "Sign with XUMM" button.
Describe the bug
I renamed one of the imported accounts from Arwèn
to XUMM Donations
. After renaming, viewing the TX history, the old account name is displayed.
The account is not in my address book (so it can't come from there). When force closing the app and restarting the Events show the right (new) account name.
Expected behavior
The renamed account is listed in the events with the new, renamed, name
When using the "send" flow, entering the destination/search box, typing a substring, only the XUMM backend service is queried, while the entered substring may also match someone in the address book (eg. name or address).
These results should (if matches) be combined under their respective own "title", eg.
[Contacts]
..
..
[Search results]
..
..
Complete e2e tests and make screenshot from all screens.
When a user imports an account, check the derived r... address, if master is disabled and a signer list is setup (instead of a regular key #15) inform the user (in the account import flow) that XUMM doesn't natively multi sign, and that they can use one of the existing XRPL toolkits with XUMM support to handle multi signing).
In the future: eg. allow the user to view a "XUMM Tools" webpage (specific Multi Sign category?) where we may track all available toolkits/apps with XUMM support » https://xrpl-labs.canny.io/xumm/p/create-a-xumm-tools-webpage
Describe the bug
Rare condition: account status is updated (eg. flag is set, @nixer89 ;) ) while the app was offline / in the background / ... Now a sign request comes in (so the user doesn't pass through the home screen of the app, where the account info is updated).
This could result in signing a payload based on old information (eg. master disabled + regular key, thus making XUMM using the regular key, while in fact the master disabled has already been cleared & regular key unset).
Expected behavior
If (async, in the background) the most recent account info is updated when opening a sign request (besides the already present subscription to account updates on the XRPL, as the event may be missed if the app is offline / in the bg) we make sure we are always working with the most recent account info when handling a sign request.
Describe the bug
When trying to delete an IOU in the Xumm App, an error is shown
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The IOU should have been deleted
What build of XUMM are you running? Please provide the full version (you can find it in Settings > Advanced).
What device are you running XUMM on?
Session Log:
[10:57:55.830] XUMM version 0.1.6.1
[10:57:55.866] Storage current schema version: 1
[10:57:55.867] Storage is on latest schema version
[10:57:55.872] Locale set to: EN
[10:57:55.880] Syncing time with network [time.google.com]...
[10:57:55.919] NTP Sync success, Network time offset UTC 29
[10:57:55.929] Start Syncing with backend
[10:57:56.136] Syncing contacts ...
[10:57:56.166] Connected to Rippled Node wss://testnet.xrpl-labs.com
[10:57:56.167] Sending Socket Payload {"command":"account_info","account":"rNixerUVPwrhxGDt4UooDu6FJ7zuofvjCF","ledger_index":"validated","signer_lists":true,"id":4}
[10:57:56.168] Sending Socket Payload {"command":"account_info","account":"r9N4v3cWxfh4x6yUNjxNy3DbWUgbzMBLdk","ledger_index":"validated","signer_lists":true,"id":5}
[10:57:56.168] Sending Socket Payload {"command":"account_info","account":"rpLyiTZR4xQnzcyZeXWJPoq3PgcdPVHPb7","ledger_index":"validated","signer_lists":true,"id":6}
[10:57:56.168] Subscribed to rNixerUVPwrhxGDt4UooDu6FJ7zuofvjCF,r9N4v3cWxfh4x6yUNjxNy3DbWUgbzMBLdk,rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG,rpLyiTZR4xQnzcyZeXWJPoq3PgcdPVHPb7 accounts ["rNixerUVPwrhxGDt4UooDu6FJ7zuofvjCF","r9N4v3cWxfh4x6yUNjxNy3DbWUgbzMBLdk","rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG","rpLyiTZR4xQnzcyZeXWJPoq3PgcdPVHPb7"]
[10:57:56.168] Sending Socket Payload {"command":"subscribe","accounts""rNixerUVPwrhxGDt4UooDu6FJ7zuofvjCF","r9N4v3cWxfh4x6yUNjxNy3DbWUgbzMBLdk","rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG","rpLyiTZR4xQnzcyZeXWJPoq3PgcdPVHPb7"],"id":7}
[10:57:56.168] Sending Socket Payload {"command":"account_info","account":"rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG","ledger_index":"validated","signer_lists":true,"id":8}
[10:57:56.203] Account info rNixerUVPwrhxGDt4UooDu6FJ7zuofvjCF {"account_data":{"Account":"rNixerUVPwrhxGDt4UooDu6FJ7zuofvjCF","Balance":"669665384","Flags":0,"LedgerEntryType":"AccountRoot","OwnerCount":0,"PreviousTxnID":"FF924879F2E6F94B5099FFA5B57245D67F06637C53C88D1FA8F1C8CB26927F2E","PreviousTxnLgrSeq":5698147,"Sequence":13,"index":"1021D8793852E3D22434F6B3990EA53FDC00353A649EBE0E2BE2324775E3F248","signer_lists"]},"ledger_hash":"27604AA65EF1CB59DCBDB32AA5C6B8AF98B00ECC60A614E93D043CDA2671B6ED","ledger_index":5723433,"validated":true,"command":"account_info","replyMs":36}
[10:57:56.214] Sending Socket Payload {"command":"account_lines","account":"rNixerUVPwrhxGDt4UooDu6FJ7zuofvjCF","id":9}
[10:57:56.215] Account info r9N4v3cWxfh4x6yUNjxNy3DbWUgbzMBLdk {"account_data":{"Account":"r9N4v3cWxfh4x6yUNjxNy3DbWUgbzMBLdk","Balance":"419999988","Flags":0,"LedgerEntryType":"AccountRoot","OwnerCount":0,"PreviousTxnID":"FD3CC50A88337E2D2113002067615BD2C11223D358E140A0DB1079874D9DF07D","PreviousTxnLgrSeq":5596198,"Sequence":2,"index":"95D62098A420099A9E77910749453FE82A3595AB34B880BACC0B5526B8661E7A","signer_lists"]},"ledger_hash":"27604AA65EF1CB59DCBDB32AA5C6B8AF98B00ECC60A614E93D043CDA2671B6ED","ledger_index":5723433,"validated":true,"command":"account_info","replyMs":46}
[10:57:56.221] Sending Socket Payload {"command":"account_lines","account":"r9N4v3cWxfh4x6yUNjxNy3DbWUgbzMBLdk","id":10}
[10:57:56.222] Account info rpLyiTZR4xQnzcyZeXWJPoq3PgcdPVHPb7 {"account_data":{"Account":"rpLyiTZR4xQnzcyZeXWJPoq3PgcdPVHPb7","Balance":"20999989","Flags":0,"LedgerEntryType":"AccountRoot","OwnerCount":0,"PreviousTxnID":"996D8D8AC0311E393943F8899FA716F7BE66475DD4423C886FD1632998A3E912","PreviousTxnLgrSeq":5667529,"Sequence":15,"index":"51F4B62FBF5A007EC0BDD76F38057F3D72A976A7CFDDB1069201C01ECFAA9E11","signer_lists"]},"ledger_hash":"27604AA65EF1CB59DCBDB32AA5C6B8AF98B00ECC60A614E93D043CDA2671B6ED","ledger_index":5723433,"validated":true,"command":"account_info","replyMs":54}
[10:57:56.229] Sending Socket Payload {"command":"account_lines","account":"rpLyiTZR4xQnzcyZeXWJPoq3PgcdPVHPb7","id":11}
[10:57:56.230] Account info rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG {"account_data":{"Account":"rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG","Balance":"92498004","Domain":"68747470733A2F2F78756D6D2E636F6D6D756E697479","EmailHash":"351107F80DE5E43F95C720D96BB5C737","Flags":65536,"LedgerEntryType":"AccountRoot","OwnerCount":3,"PreviousTxnID":"FF924879F2E6F94B5099FFA5B57245D67F06637C53C88D1FA8F1C8CB26927F2E","PreviousTxnLgrSeq":5698147,"Sequence":84,"index":"51C3512735E28DF6165266F2A2709E49F6028E6382D0D6D70D0DE404CAB39BD5","signer_lists"],"urlgravatar":"http://www.gravatar.com/avatar/351107f80de5e43f95c720d96bb5c737"},"ledger_hash":"27604AA65EF1CB59DCBDB32AA5C6B8AF98B00ECC60A614E93D043CDA2671B6ED","ledger_index":5723433,"validated":true,"__command":"account_info","__replyMs":62}
[10:57:56.248] Sending Socket Payload {"command":"account_lines","account":"rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG","id":12}
[10:57:56.352] Sending Socket Payload {"command":"account_info","account":"rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq","ledger_index":"validated","signer_lists":true,"id":13}
[10:57:56.353] Sending Socket Payload {"command":"account_info","account":"rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq","ledger_index":"validated","signer_lists":true,"id":14}
[10:58:00.536] Submit TX: {"TransactionType":"TrustSet","Account":"rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG","Flags":2147614720,"LimitAmount":{"currency":"EUR","issuer":"rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq","value":0},"Fee":"12","Sequence":84}
[10:58:00.538] Sending Socket Payload {"command":"account_info","account":"rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG","ledger_index":"validated","signer_lists":true,"id":17}
[10:58:00.706] Sending Socket Payload {"command":"submit","tx_blob":"1200142280020000240000005463800000000000000000000000000000000000000045555200000000002ADB0B3959D60A6E6991F729E1918B716392523068400000000000000C732102A896AC755006AC8F3BCC86D4816DCEC43808C1A576E9B52FDF8017E3F24AAF53744730450221008D9E3F7FACAC4D51F4C0543C34E4E74125ED3DCC7CE73B2C977F83A07CFC26AE022057FC3A4742E849347457BE8B36FE95E7495A84A3FC7F4191A5A42BA70FC59CAE81146E965AA3CC658518E579480DFD81D8CB06085602","id":18}
There is two new Alternative JS core for android
base on this post looks like v8 is a really good option.
Right now realm doesn't support other alternative js cores , so we have to wait to they implement this feature
When starting the app, during the app splash screen, XUMM is connecting to the configured XRPL node. If there's trouble with the network, this may take a while.
So, during the splash screen:
Connecting to the XRP ledger...
This is taking more time than usual...
Please check your internet connection
screen, allow users to try again. If that doesn't work, allow users to switch node.Describe the bug
When sending a TrustSet transaction to Xumm, an weird error is shown after signing the transaction
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Even if the TrustSet transaction is not valid, a proper Error message should be shown
What build of XUMM are you running? Please provide the full version (you can find it in Settings > Advanced).
What device are you running XUMM on?
the submitted payload looks like this (and was signed with testnet account):
{"options":{"expire":5},"txjson":{"TransactionType":"TrustSet","LimitAmount":{"issuer":"rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq","currency":"ABC","value":"100"}},"custom_meta":{"instruction":"- Issuer Address: rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq\n- IOU currency code: ABC"}}
SessionLog cannot be copied because the app shows only a white screen. Only after force closing the app it's working again but SessionLog is overwritten.
Describe the bug
Some parts/movdment of the interface scroll the content panel up, and some parts the actual content. Maybe we should fix the panel when focused in the amount (or any other input for that matter)
Expected behavior
Swiping the screen up/down without moving the panel. Maybe keep the panel fixed when focussed at the input.
Screenshots
https://lufunlq.dlvr.cloud/trim.3C6995DB-30E3-4CD9-B3B0-0B64F127470D.MOV
iPhone X
Describe the bug
When opening and focusing the amount, it scrolls towards the field but it's not really visible as only the top pops out from under the keyboard
Expected
When focussing on the amount, keep the amount in the visible viewport
Screenshots
https://gqubonl.dlvr.cloud/trim.53DD5ACF-246B-4AAE-AD61-00B64803949D.MOV
iPhone X
When filtering events, you type something, the events are filtered. So far so good.
Now (by tapping outside of the filter textbox (input)) the keyboard will still be displayed, focus still in the filter search input. This limits the amount of screen space available to review the found transactions. Look eg. at Bunq: to apply (text) filter, one has to press the "search" button @ keyboard, then the input blurs, keyboard goes away and filter starts.
The "Events" page for accounts now shows the transaction history. It would make sense to find a place that makes sense where one can browse the account_objects
too, like the open escrows and the offers. The user should then be offered context related buttons, eg. in case of an offer: cancel, in case of an escrow: finish / cancel (if possible).
Recap:
account_info (if a master key is disabled Y/N, if a regular key is set Y/N) isn't always up to date, resulting in signing with or without a regular key while that's no longer required (or no longer possible).
Description
Signing of new Transactions via XUMM fails when:
To Reproduce
Steps to reproduce the behavior:
There are two ways to reproduce it:
A:)
OR
B:)
Expected behavior
The transaction should be signed with the Regular Key/Master Key. But instead it seems XUMM tries to sign with the Master Key/Regular Key
Screenshots
See above!
What build of XUMM are you running? Please provide the full version (you can find it in Settings > Advanced).
What device are you running XUMM on?
Session Logs can not be provided because App crashes when opening the Session Log (separate Issue)
When a user imports an account, and the derived r... address has the master key disabled and a regular key configured, explain to the user (in the setting up flow) that to make transaction signing work for this account, they will have to import the regular key account as well.
XV5sbjUmgPpvXv4ixFWZ5ptAYZ6PD2q1qM6owqNbug8W6KV
or rPEPPER7kfTD9w2To4CQk6UCfuHM9c6GDY:495
Destination Tag
field is empty ❗️Allow users to select (on a per account basis) to get (background) push notifications for incoming transactions (for full access accounts, so ownership is verified)
This will be added in the future, but probably only for XUMM Pro subscriptions (as we'd need to provide infrastructure to run this).
Describe the bug
When closing the input doesn't blur so the keyboard is over the close modal.
Expected behavior
Blur when tapping the Close button, thus closing the keyboard as well
Screenshots
https://lufunlq.dlvr.cloud/trim.3C6995DB-30E3-4CD9-B3B0-0B64F127470D.MOV
iPhone X
** Would be considered a bug by end users. **
Right now, when a user uses the QR scanner icon from the home screen, when scanning a QR code containing an XRPL destination (r-address, X-address) nothing happens. Scanning a destination only works from the "Send" flow.
I'm 100% positive this will result in a crazy amount of bug reports/questions. Users should just be able to scan without having to think about what they are scanning.
So: when a user scans a destination from the home screen scanner, route the user to the Send flow with the destination address (and tag if present, see #17 + #18) already prefilled.
Users will try to add their exchange hot wallets as a read only account to XUMM, assuming they can somehow track their exchange balance by destination tag.
When adding a read only wallet, we should give a big fat warning message in the screen to inform the user that they can NOT track their own transactions from an exchange hotwallet using this feature.
Currently, when a payload contains a return URL for app
, this return URL is only triggered when a user signs the payload.
If a user declines the payload (rejects), the user returns to the app home screen. This results in the user never returning to the originating application (if they are using a deeplink app to app flow).
So: when the payload contains an app
return URL, and the user fully declines (not closes) the payload, ask the user if they want to return home, or want to go back to `.
Describe the bug
When trying to open the SessionLog, the App crashes. But only when a XRPL transaction was executed before
To Reproduce
Steps to reproduce the behavior:
Expected behavior
SessionLog should be shown.
What build of XUMM are you running? Please provide the full version (you can find it in Settings > Advanced).
What device are you running XUMM on?
Attach crash logs if available. Please ensure that these files do not contain any personal information.
When (XUMM home screen) tapping "add" (Other currencies), a currency + issuer that is already present (Trust line already exists) is still offered. It doesn't make sense to offer adding the currency again.
Better app performance guideline :
https://github.com/wix/react-native-crash-course/blob/master/docs/App.performance.md
Allow users to review all XUMM apps with push access, and allow a user to revoke push access. When revoking, somehow allow the user to report the app as well. Too many reports for a specific app = trigger (to XRPL Labs) to review the app.
After the "Not executed due to lack of liquidity" message @ exchanging on DEX, check if the transaction is at least partially fulfilled.
If not fulfilled: take the user back to the home screen. If partially fulfilled: take them to the transaction details screen where they can see the outcome, so at least they know what actually happened (how much was exchanged anyway).
In my sample case, I ordered 0.25 BTC to be exchanged but only 0.06 made it (as XUMM allows at most a 10% difference between the best exchange rate and the amount to be spent). Without taking people to details they may try it again not knowing that it already partially fulfilled.
The last 50 records are currently displayed. When devs want to debug older requests they should be able to browse back in the request log.
When filtering (text) the events, searching doesn't filter the account names (from address book / lookup / ...), just transaction account and hash. People will definitely try to search for the name, so it should filter the name as well.
Right now, when sending XRP, first the source account, currency and amount are entered.
After that, the destination is selected (enter account / scan a QR).
Then, one goes to the final screen to enter meta info and ... The destination tag.
That doesn't make sense; the Destination tag is part of the destination so it belongs on the screen where the destination account is entered and selected. It can even be very confusing to end users as they can't find a place to enter the tag when selecting the destination.
Describe the bug
When exchanging an IOU for XRP (or the other way around), you can enter any amount (even more than you own, which is OK and works just fine as the transaction will exchange as much as possible based on the amounts entered).
But: after conversion, the ENTERED amounts are returned to the user, not the effective OUTCOME amounts. It should display the outcome (effective, real workd) results from the finished transaction.
To Reproduce
Expected behavior
Display the ACTUAL consumed balance and credited value.
Describe the bug
When redirecting a user to the next.always URL of the payload response (as example on desktop) a QR code is shown. If the QR code is expired, the website (https://xumm.app/sign/:payloadId) does not redirect back to the original application and the user is "stuck" in this screen.
When scanning the expired QR code, there will be a proper error message in the app but the website says "Waiting for you to resolve (accept / deny) the "Payment" request in XUMM app."
But that is not possible because the payload has expired before it was opened/scanned.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
It would be cool if the website (https://xumm.app/sign/:payloadId) shows an error/warning when the
payload has expired and offers the possibility to redirect to the original page like:
"The payload has expired and cannot be signed anymore. Click here to return to the previous website"
(not so important here. Not app bug :-) )
Describe the bug
See title
To Reproduce
Expected behavior
Removed currency gone
Push notifications can be sent translated as well, by getting the device_appLanguage
on a per user-per device basis.
Report by @nixer89
I opened the app. had an account A and an Account B. I set Account B as regular key for account A. Then I disabled the master key for Account A. Then I tried to enable the master key for Account A back and the transaction failed. (as info: I never left the "events" screen of the Xumm App!)
But once I navigate to the "Home" screen, transactions are possible. My conclusion: After transaction submission and verification to the XRPL ledgter, the app does not refresh the account settings of all accounts, therefore is not aware that a regular key was set
because it does not know of the new regular key, the app still tries to sign the next transaction with the master key
once I navigate to the "Home" screen, the account_info's of all accounts are refreshed and the app is aware of the regular key relation and can sign the next transaction with the regular key
so is it possible to refresh the account_info (and even account_objects) after transaction verification?
Suggested solution: refresh account info after sending a transaction that affects the account state, eg. AccountSet
, SetRegularKey
, ...
Describe the bug
When sending or handling a sign request sending an IOU, XUMM checks if the sender (you) and the recipient have the same trust line setup (for that IOU). If so, the amount will be sent as the IOU currency. If not, a conversion will take place sending XRP to the destination (using DEX).
However, when depositing the IOU back to the issuer (eg. sending Bitstamp USD back to Bitstamp for fiat withdrawal) the recipient DOESN'T have the trust line, as they are the issuer.
To Reproduce
Send eg. USD / BTC IOU back to IOU deposit address @ Bitstamp, eg.
Sample TX:
5456C8D189A58D0BBC3D932527DAB3522C78D6516AEF37287AA971D240E3305C
Expected behavior
IOU sent as is, Bitstamp USD sent, Bitstamp USD delivered.
Screenshots
If applicable, add screenshots or a video to help explain your problem.
Sending the IOU as-is (without conversion to XRP) if (we need to check for two things):
When a deeplink opens the app and the transaction is expired (eg. try the link at https://wietse.nodum.io/test/expired-deeplink) the app shows a message that the transaction has been "handled by another client", which is not the case: the message should be different when expired.
If expired: "The request expired"
If not expired, but handled by another client: "This request is already resolved"
If the Event-detail page (transaction detail view) gets updated to show more clear (tx instruction vs. outcome) information & context aware (#10) buttons (eg. escrow: if possible: release/cancel, if not possible yet: show when. If AccountSet, set flag: clear flag & reversed, if Offer: cancel offer, if possible) »
Once a transaction has been successfully sent, allow users to select (if not by sign request with redirect URL for app) where they want to go: Home
or Transaction details
» and link them to the improved TX detail screen just mentioned.
Other ideas:
For EscrowFinish transactions:
Sample: TX: 8AD4A1E7B1E138ECB6C6A3A9BF450A9F26E73797379C15C55E37754FC1DB7602, escrow from TipBot to account rKLhe74ERouyMADhiRvZaya6266b2wxZjy, released by the TipBot. Balance mutated with +5.
For EscrowCreates TO own account, show a "light/grey/..." amount, because it's not final yet.
Describe the bug
When opening the app (when started and minimized before) the open screen (with balances, if home screen) is visible for a short period of time, after the blur comes into effect and the PIN/Face/FingerprintId has to be used to unlock the app.
This should be blurred in the first place, or show the start/lock screen (logo) until the app is unlocked to prevent people from accidentally exposing details for a short instance (account holdings / transactions) when opening the app from the background (and it's less confusing)
See (screencap): https://eqymxe3.dlvr.cloud/RPReplay_Final1585130709.mp4
Describe the bug
See:
https://kcokjkv.dlvr.cloud/trim.1BD74FCA-660E-43BF-B638-690307A34803.MOV
Expected behavior
Message that at least one drop should be sent.
Screenshots
https://kcokjkv.dlvr.cloud/trim.1BD74FCA-660E-43BF-B638-690307A34803.MOV
When at the Events / Profile / Settings page, allow a swipe from the left screen edge to right to return back home (just like the "Send" screen now does).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.