Do some validation if the user input in `NewChannelDialog` before
allowing to click the `Ok` button. This is done to make the UI a bit
more intuitive and prevent issues like #10053 in which the user was able
to click `Ok` with a empty trampoline node list which raised an
`IndexError` (probably on testnet4).
exc triggered when switching from same server to same server:
```
9.43 | D | gui.qml.qenetwork | server_status updated: Connecting
9.43 | E | network | Exception in _run_new_interface: Exception('diagnostic name not yet available?')
Traceback (most recent call last):
File "/home/user/wspace/electrum/electrum/logging.py", line 241, in __get_logger_for_obj
diag_name = self.diagnostic_name()
File "/home/user/wspace/electrum/electrum/interface.py", line 555, in diagnostic_name
return self.server.net_addr_str()
AttributeError: 'str' object has no attribute 'net_addr_str'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/user/wspace/electrum/electrum/util.py", line 1218, in wrapper
return await func(*args, **kwargs)
File "/home/user/wspace/electrum/electrum/network.py", line 986, in _run_new_interface
interface = Interface(network=self, server=server)
File "/home/user/wspace/electrum/electrum/interface.py", line 502, in __init__
Logger.__init__(self)
File "/home/user/wspace/electrum/electrum/logging.py", line 232, in __init__
self.logger = self.__get_logger_for_obj()
File "/home/user/wspace/electrum/electrum/logging.py", line 243, in __get_logger_for_obj
raise Exception("diagnostic name not yet available?") from e
Exception: diagnostic name not yet available?
```
`TxDialog` may has to fetch tx information from the network on
construction (`self.set_tx()`) and is showing a `RunCoroutineDialog`.
If the user cancels this dialog the `UserCancelled` exception is not
caught in `show_transaction()` and can even lead to Electrum crashing.
Fixes#10041
Fixes exception occuring when `wallet.lnworker` is `None` and the user
clicks on `New Channel` in the channels list tab. The `New Channel`
button is enabled when the wallet *can* have lightning, not the wallet
actually having lightning enabled.
With this patch the `init_lightning_dialog` will show up if the user
clicks on `New Channel` but lightning is not yet enabled.
I noticed this by restoring from a funded vpub and then
loading the keystore from seed afterwards.
```
319.55 | E | gui.qml.qeapp.Exception_Hook | exception caught by crash reporter
Traceback (most recent call last):
File "...\electrum\electrum\util.py", line 1130, in run_with_except_hook
run_original(*args2, **kwargs2)
File "...\Python310\lib\threading.py", line 953, in run
self._target(*self._args, **self._kwargs)
File "...\plyer\platforms\win\libs\balloontip.py", line 206, in balloon_tip
WindowsBalloonTip(**kwargs)
File "...\plyer\platforms\win\libs\balloontip.py", line 130, in __init__
raise Exception('Could not load icon {}'.format(app_icon))
Exception: Could not load icon ...\electrum\electrum\gui\icons\electrum.png
```
When closing Electrum with open `ConfirmTxDialog` the following
exception is raised:
```
1319.20 | E | gui.qt.exception_window.Exception_Hook | exception caught by crash reporter
Traceback (most recent call last):
File "/home/user/code/electrum-fork/electrum/gui/qt/send_tab.py", line 575, in do_pay_or_get_invoice
self.do_pay_invoice(self.pending_invoice)
~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/code/electrum-fork/electrum/gui/qt/send_tab.py", line 602, in do_pay_invoice
self.pay_onchain_dialog(invoice.outputs, invoice=invoice)
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/code/electrum-fork/electrum/gui/qt/send_tab.py", line 328, in pay_onchain_dialog
tx, is_preview = self.window.confirm_tx_dialog(make_tx, output_value, batching_candidates=candidates)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/code/electrum-fork/electrum/gui/qt/main_window.py", line 1502, in confirm_tx_dialog
return d.run(), d.is_preview
~~~~~^^
File "/home/user/code/electrum-fork/electrum/gui/qt/confirm_tx_dialog.py", line 477, in run
self.stop_editor_updates()
~~~~~~~~~~~~~~~~~~~~~~~~^^
File "/home/user/code/electrum-fork/electrum/gui/qt/confirm_tx_dialog.py", line 133, in stop_editor_updates
self.main_window.gui_object.timer.timeout.disconnect(self.timer_actions)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'timeout'
```
This can be prevented by checking if `main_window.gui_object.timer` is
None before trying to disconnect it.
- save custom fixed feerate fee_policies, not just slider-restricted ones
- dynamically update fee_target text, to follow feerate_e
- otherwise when the slider is set to "feerate", users would be shown two conflicting values
When clicking the "close_button" button (labelled "Not Now"), the whole app state got bugged:
none of the existing windows (e.g. ElectrumWindow) could get focus anymore.
The signature of PushButton.clicked is:
`void QAbstractButton::clicked(bool checked = false)`
https://doc.qt.io/qt-6/qabstractbutton.html#clicked
and pyqt is probably doing some polymorphism, dynamically deciding if the qt slot wants the "checked" arg or not.
The extremely weird part is that the bug is triggered on clicking "close_button" (probably pyqt is passing "checked" to self.close)
but instead of the current commit, the following diff, touching a completely different button, would also "fix" the issue:
```
diff --git a/electrum/gui/qt/exception_window.py b/electrum/gui/qt/exception_window.py
index eceab89de6..e0162e5827 100644
--- a/electrum/gui/qt/exception_window.py
+++ b/electrum/gui/qt/exception_window.py
@@ -67,7 +67,7 @@ class Exception_Window(BaseCrashReporter, QWidget, MessageBoxMixin, Logger):
self._report_contents_dlg = None # type: Optional[ReportContentsDialog]
collapse_info = QPushButton(_("Show report contents"))
- collapse_info.clicked.connect(self.show_report_contents_dlg)
+ collapse_info.clicked.connect(lambda: self.show_report_contents_dlg())
main_box.addWidget(collapse_info)
```
No idea why.
deletes the `seed_type` key from `wizard_data` in `WCWalletType` if it
is not explicitly set to prevent a stale value from a previous wizard
flow if the user goes back in the wizard and selects a different wallet
type instead of completing the wizard with the previously selected
wallet type.
This happens as the `apply()` function gets called with the
previously set radio button (e.g. 2fa) if the user goes back, if he then
selects multisig the `2fa_segwit` `seed_type` won't get cleared and
cause the exception later.
Example exception when first selecting 2fa, then going back and creating
a multisig wallet:
```
32.77 | E | gui.qml.qeapp.Exception_Hook | exception caught by crash reporter
Traceback (most recent call last):
File "/home/vagrant/electrum/electrum/gui/qml/qewizard.py", line 40, in submit
view = self.resolve_next(self._current.view, wdata)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/vagrant/electrum/electrum/wizard.py", line 78, in resolve_next
view_accept(wizard_data)
File "/home/vagrant/electrum/electrum/wizard.py", line 501, in maybe_master_pubkey
wizard_data['multisig_master_pubkey'] = self.keystore_from_data(wizard_data['wallet_type'], wizard_data).get_master_public_key()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/vagrant/electrum/electrum/wizard.py", line 339, in keystore_from_data
return keystore.from_seed(data['seed'], passphrase=seed_extension, for_multisig=for_multisig)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/vagrant/electrum/electrum/keystore.py", line 1197, in from_seed
raise BitcoinException('Unexpected seed type {}'.format(repr(t)))
electrum.util.BitcoinException: Unexpected seed type '2fa_segwit'
```
Triggered by the following wizard stack:
```
30.94 | D | wizard | view=create_seed
30.94 | D | wizard | resolve_next view is confirm_seed
30.94 | D | wizard | wizard stack:
0: 0x7fdc6804ae80 - {}
1: 0x7fdc6ac61400 - {'wallet_name': 'wallet_1'}
2: 0x7fdc680d8a80 - {'seed_type': '2fa_segwit', 'wallet_name': 'wallet_1', 'wallet_type': 'multisig'}
3: 0x7fdc6804ab00 - {'multisig_cosigner_data': {}, 'multisig_participants': 2, 'multisig_signatures': 2, 'seed_type': '2fa_segwit', 'wallet_name': 'wallet_1', 'wallet_type': 'multisig'}
4: 0x7fdc6807f0c0 - {'keystore_type': 'createseed', 'multisig_cosigner_data': {}, 'multisig_participants': 2, 'multisig_signatures': 2, 'seed_type': '2fa_segwit', 'wallet_name': 'wallet_1', 'wallet_type': 'multisig'}
c: 0x7fdc6807c380 - {'keystore_type': 'createseed', 'multisig_cosigner_data': {}, 'multisig_participants': 2, 'multisig_signatures': 2, 'seed': '<redacted>', 'seed_extend': False, 'seed_extra_words': '<redacted>', 'seed_type': '2fa_segwit', 'seed_variant': 'electrum', 'wallet_name': 'wallet_1', 'wallet_type': 'multisig'}
30.94 | W | gui.qml.qeapp | next view: confirm_seed
```
- the msg_box did not allow neither vertical nor horizontal scrolling
- long lines were not word-wrapped, but were effectively truncated
- long reports could only be inspected if the user somehow selected
the full text and pasted it into a text editor
- new dialog allows vertical and horizontal scrolling
- we could maybe word-wrap instead of horizontal scrolling,
but this is already a strict improvement for long reports
when setting a transaction label in the qml
`LightningPaymentDetails` or `TxDetails` dialogs which get opened
directly by the `ReceiveDialog` (`onRequestPaid`) the label is not applied on the main
transaction list as no callback for `detailsChanged` is registered which
gets called when the label changes. As a result the label is only
visible after the main list gets reloaded (e.g. restart).
This commit adds callbacks for `detailsChanged` to fix this.
The implementation is just
bool QAbstractItemModel::hasIndex(int row, int column, const QModelIndex &parent) const
{
if (row < 0 || column < 0)
return false;
return row < rowCount(parent) && column < columnCount(parent);
}
and yet it features as the most prominent part of the profile,
encompassing up to 25% of refresh()
Open-coding it makes refresh() 40% faster. Measurements from between
after wallet.get_full_history() and return from refresh()
Before:
1.8637257907539606
1.8563996930606663
1.7696567592211068
1.8933695629239082
After:
1.3133591176010668
1.3686819169670343
1.2470976510085166
1.2455544411204755
endInsertRows() triggers a sort, the history sort/filter proxy model
then launders the comparison requests through get_data_for_role()
with a custom key, which is then especially looked up in there,
but custom-flattened in the proxy model. This is OO hell
Measuring refresh() from after if transactions == self.transactions: return
to the final return, sorting the wallet from #9958/#6625 takes ~3.5s
and 132348 get_data_for_role() calls
Beside that get_data_for_role() is called maybe 10 times per on-hover?
It's immaterial
Thus: compute the sorting keys when constructing the HistoryNode
and use them directly in the comparison.
This decouples get_data_for_role() from the sorter
and speeds the sort up by ~2x,
now being mostly made up of the python interpreter overhead(?)
for upcalls to lessThan()
A dict wins with a list for the lookup a tiny bit
(and is 100x better code-wise):
1.896097298245877s list
1.840533264912665s list
1.757185084745288s list
1.8990754359401762s list
1.914668960031122s list
1.9349112827330828s list
2.432649422902614s list
1.929884395096451s list
1.9610795709304512s list
1.8694845158606768s list
1.9600030612200499s list
1.9199693519622087s dict
2.0466488380916417s dict
1.8510140180587769s dict
1.8978681536391377s dict
2.0079748439602554s dict
1.9111531740054488s dict
1.9525738609954715s dict
1.850804285146296s dict
1.860573346260935s dict
1.95173170696944s dict
1.8481200002133846s dict
Benchmark 1: dict
Time (mean ± σ): 1918.039234 ms ± 63.688609 ms
Range (min … max): 1848.120000 ms … 2046.648838 ms 11 runs
Benchmark 2: list
Time (mean ± σ): 1945.052027 ms ± 164.019588 ms
Range (min … max): 1757.185085 ms … 2432.649423 ms 11 runs
Summary
'dict' ran
1.014084 ± 0.090082 times faster than 'list'
if there is no amount in the payment request the notification would look
weird as it would just show `Payment received:` indicating something
might be missing. Now it just says `Payment received` instead.
and differenciate between a single 'provider' and multiple or 0
'providers'. Also update SwapDialog and SwapServerDialog
when new offers are incoming. Stops translating f-string.
