Catch JavaError when trying to load the java classes of the biometry
module on startup. This can raise if the device is on an old API version
and the loaded java class depends on apis unknown to the os.
Fixes#10470
```
02-17 10:07:25.714 5254 5270 I python : 0.47 | E | __main__ | daemon.run_gui errored
02-17 10:07:25.714 5254 5270 I python : Traceback (most recent call last):
02-17 10:07:25.714 5254 5270 I python : File "app/main.py", line 514, in handle_cmd
02-17 10:07:25.714 5254 5270 I python : File "app/electrum/daemon.py", line 653, in run_gui
02-17 10:07:25.714 5254 5270 I python : File "app/electrum/gui/qml/__init__.py", line 38, in <module>
02-17 10:07:25.714 5254 5270 I python : File "app/electrum/gui/qml/qeapp.py", line 49, in <module>
02-17 10:07:25.714 5254 5270 I python : File "app/electrum/gui/qml/qebiometrics.py", line 33, in <module>
02-17 10:07:25.714 5254 5270 I python : File "jnius/reflect.py", line 243, in autoclass
02-17 10:07:25.714 5254 5270 I python : File "jnius/jnius_export_class.pxi", line 877, in jnius.jnius.JavaMethod.__call__
02-17 10:07:25.714 5254 5270 I python : File "jnius/jnius_export_class.pxi", line 964, in jnius.jnius.JavaMethod.call_method
02-17 10:07:25.714 5254 5270 I python : File "jnius/jnius_utils.pxi", line 79, in jnius.jnius.check_exception
02-17 10:07:25.714 5254 5270 I python : jnius.jnius.JavaException: JVM exception occurred: Failed resolution of: Landroid/hardware/biometrics/BiometricPrompt$AuthenticationResult; java.lang.NoClassDefFoundError
```
please, use common sense :(
I guess it was a copy-paste error, but still, treat all _() and qsTr() calls as "scary" and as potential attack vectors. Don't blindly call _(): every call needs to be weighed separately.
Differentiate between the `UserFacingException` and other exceptions
when creating the storage. Forward other exceptions to the reporter so
they can get fixed.
Same as Qt, validate the server address the user enters and prevent the
user from continuing in the wizard or clicking 'Ok' in the ServerConfig
if the entered address is clearly invalid.
Disables the "Always allow Screenshots" switch in the preferences if the
App isn't running on Android. QML doesn't have screenshot protection
outside of Android so this toggle is misleading.
Currently the PasswordDialog on QML would just close if the user enters
an incorrect password. This is confusing as the user doesn't know why
the dialog closed and if it initiated any action or not.
With the change the PasswordDialog will get the ability to show an error
message and will show "Invalid Password" if an incorrect password is
entered.
I also used it for the password unification warning ("Need to enter
similar password ...") instead of showing a separate popup.
This must be an old regression.
The GUI was not allowing to open a wallet that did not have a password set:
it prompted for a password and did not accept any string (should at least accept empty "").
Without this, it was only possible to open a passwordless wallet if that was the first wallet the user opened
(as otherwise we would overwrite the empty pw with the pw of the current wallet).
Completely removes the pin code authentication from qml. The config
option in the wallet preferences has been renamed to "Payment
authentication" and now either asks for the Android system
authentication (Biometric or system pin/password) if enabled or will ask
for the wallet password as fallback.
Fixes the issue described in #10406.
When scanning a lightning invoice we would pass it to
`QEInvoiceParser.fromResolvedPaymentIdentifier()`, however
`fromResolvedPaymentIdentifier()` doesn't reset the state of
`QEInvoiceParser._lnurlData` which is used in QML to evaluate
`payImmediately: invoiceParser.isLnurlPay` in the `onValidationSuccess`
connection.
This change calls `clear()` in `fromResolvedPaymentIdentifier()` to
ensure that `QEInvoiceParser` state gets reset when loading a new invoice.
However when retrieving a bolt11 from a lnurl-pay callback we don't
wan't to reset `QEInvoiceParser._lnurlData` so that `payImmediately` is
true when confirming the lnurl pay dialog, for that I skip calling
`fromResolvedPaymentIdentifier()` and instead call `validateRecipient()`
directly so the `QEInvoiceParser` state doesn't get reset in this case.
Adds close() no-op method to QEQRScanner to prevent type errors like
this:
```
01-02 17:28:09.645 10543 10565 I python : 162.27 | W | gui.qml.qeapp | file:///data/data/org.electrum.electrum/files/app/electrum/gui/qml/components/SweepDialog.qml:123: TypeError: Property 'close' of object QEQRScanner(0xdd32f66fb600)
is not a function
```
- LNWallet no longer "is-an" LNWorker, instead LNWallet "has-an" LNWorker
- the motivation is to make the unit tests nicer, and allow writing unit tests for more things
- I hope this makes it possible to e.g. test lnsweep in the unit tests
- some stuff we would previously have to write a regtest for, maybe we can write a unit test for, now
- in unit tests, MockLNWallet now
- inherits LNWallet
- the Wallet is no longer being mocked
QEWalletListModel.remove_wallet was calling beginRemoveRows with i
instead of remove as index, causing it to not delete the wallet from the
list and the wallet list becoming broken after deleting a wallet.
If the user has wallets with different passwords (non-unified pw) and
enters a password on startup that fails to unlock the recently used
wallet this change will automatically open any other wallet if there
is another wallet that can be unlocked with this password.
When closing the OpenWalletDialog without unlocking a wallet the
LoadingWalletDialog wouldn't get properly cleaned up as the
LoadingWalletDialog.visible was never set true. This causes the
connections to accumulate and the callbacks won't get unregistered after
closing the LoadingWalletDialog again.
Shows Wallets.qml as root if no wallet is loaded and removes the logic
for no loaded wallet from the WalletMainView as WalletMainView won't be
shown anymore without a Daemon.currentWallet.
In the GUI, when displaying the list of disconnected servers, we were
filtering to only ":s" servers. Instead now we also show ":t" servers
if they are bookmarked.
Also, if bookmarked, we also show disconnected .onion servers, even
when not using a Tor proxy.
fixes https://github.com/spesmilo/electrum/issues/10374
If a qml user with non-uniform wallet passwords tries to change their wallet
password this will force them to change it to a password that is used by
at least one other wallet. This will guide them towards a single wallet
password and prevents the number of different passwords from increasing.
If the user has not unlocked any wallet yet and tries to create a new
wallet in the overview a dialog will prompt them to first unlock an
existing wallet in order to be able to create a new wallet.
This ensures they remember at least one password so they can complete
the wizard. The wizard will ask them for an existing password later and
it would be annoying for the user to go through all steps (writing down
the seed etc.) only to find out they need a password they don't
remember. This way they can reinstall the app right before going through
the wizard.
also improve warning box styling consistency across finalizers,
add CPFP new feerate > old feerate check,
add relayfee checks for CPFP, DSCancel,
proper warning string for no dynamic fee estimates
When creating a new wallet in a Electrum instance with existing wallets
this change forces the user to reuse a password of any existing wallet
if `SimpleConfig.WALLET_USE_SINGLE_PASSWORD` is True.
This prevents the amount of different passwords from increasing and
guides the user towards a single wallet password (the intended default).
Allows storing two different payment info of the same payment hash by
including the direction into the db key.
We create and store PaymentInfo for sending attempts and for requests (receiving),
if we try to pay ourself (e.g. through a channel rebalance) the checks
in `save_payment_info` would prevent this and throw an exception.
By storing the PaymentInfos of outgoing and incoming payments separately in
the db this collision is avoided and it makes it easier to reason about
which PaymentInfo belongs where.