ACINQ / phoenix

Phoenix is a self-custodial Bitcoin wallet using Lightning to send/receive payments.
https://phoenix.acinq.co
Apache License 2.0
679 stars 98 forks source link

(ios) Various UI fixes #634

Closed robbiehanson closed 1 month ago

robbiehanson commented 1 month ago

Various UI bugs have been fixed:

a) upon receiving a payment that opens a channel (i.e., this is the case where the incoming payment should show the fee), then the splash screen does not show the fee. However it you close the details, then opens it again (for the same payment), then it shows the fee correctly.

Fixed in ab99997cba564f2ebac7af1ae427df859a402d39

b) the "caused by" link button should have a max width (like show the first 8 chars), it would look better and it would also make the ? button more visible (right now the ? is squished at the edge of the screen)

Fixed in b5fd857b9e3d0ae03417328e32bd7fbb19675a10

c) payment details screen from Home: the Details / Edit buttons are too tall (see the grey line separator)

Fixed in c65e28418a7aa6cc907db05e6f9ba3c062bd85e6 (bug only reproduces in iOS 16)

d) payment details screen from payments history: the Details / Edit / Delete buttons are weirdly aligned

Fixed in c65e28418a7aa6cc907db05e6f9ba3c062bd85e6 (bug only reproduces in iOS 16)

e) if the payment is unconfirmed, then first we show a spinner while we check Electrum for confirmation -- section which height is X -- and once we got that confirmation status, we display "0 confirmation" + "broadcast at ...." -- section which height is Y. Since X < Y, then the whole UI is jumps around when we get the confirmation result, which does not look good

Fixed in 1000bc56ac93098d6b55283d44f596723aba894a

f) clicking on the "backup your recovery phrase" notification in the Home navigates to the settings screen and not the recovery phrase screen

Fixed in 80c08270d1abeeed09d2fec4d497374018111c92 (bug only reproduces in iOS 16)


We also encountered some issues because we were testing with the same seed on both testnet & mainnet. Part of the problem was due to overlapping Preference keys.

For example, we had a key called hasDownloadedPayments, that was stored using the name hasDownloadedPayments-(encryptedNodeID). This would help us differentiate between different wallets, but didn't properly differentiate in the above scenario.

So now we use a smarter key structure: