forked from bitcoinafterlife/bal-electrum-plugin
fix(gui): window z-order + lifecycle (B1-B10) (#2)
* fix(gui): correct window z-order and lifecycle bugs (B1-B10)
Sintomi risolti:
- S1: le finestre del plugin sparivano dietro Electrum
- S2: alcuni meccanismi funzionavano solo dopo chiusura+pulizia di Electrum
La logica di business resta BYTE-IDENTICA (nessuna modifica a bal/core/*):
cambiano solo parent, modalità, ciclo di vita, cleanup e presentazione.
Nuovo modulo bal/gui/qt/window_utils.py con helper centralizzati:
- top_level_of, bring_to_front, stop_thread, show_modal, show_on_top
Fix per bug:
- B1: self.parent -> self._bal_parent (dialogs/lists/widgets); parent = top_level_of(parent)
- B2/B9: .show() -> show_on_top()/show_modal()/bring_to_front()
- B3: init a caldo _setup_window() replica load_wallet (niente 'restart Electrum')
- B4: chiave finestra stabile _window_key() = id(window)
- B5: on_close riscritto (no except:pass, log per-step, reset stato)
- B6: BalBlockingWaitingDialog ripristina processEvents()
- B7/B8: closeEvent/hideEvent -> stop_thread() (stop+wait) + super()
- B10: uso di window.tools_menu (no ricerca per titolo localizzato '&Tools')
Test: smoke + gui_fixes (regressione B1-B10) + external_zip tutti verdi.
Doc aggiornata: DIAGNOSI_GUI.md marca B1-B10 come FIXED.
* fix(gui): do not kill task thread on dialog close (download list regression)
The B7/B8 change added stop_thread() to BalDialog.closeEvent/hideEvent.
But Electrum's TaskThread.on_done runs cb_done (often self.accept, which
closes the waiting dialog) BEFORE cb_result (on_success, which updates the
will-executor list). Stopping/joining the thread inside closeEvent therefore
tore the thread down before on_success ran, silently dropping the downloaded
will-executor list ('Download List' appeared to do nothing).
Restore the original safe behavior: the base BalDialog no longer stops the
thread on close/hide (matching the original plugin, which deliberately left
this commented out). Long-lived dialogs that own a thread still stop it
explicitly in their own handlers.
Adds a regression test asserting BalDialog.closeEvent/hideEvent never call
stop_thread.
* fix(gui): restore modal exec for waiting dialog + surface download failures
Two changes to fix 'Download List' doing nothing:
1) BalWaitingDialog.exe() now keeps the original application-modal exec()
(only adding raise/activate for visibility). The earlier switch to
window-modal could interfere with how the TaskThread result (on_success,
which populates the will-executor list) is delivered via a queued signal
while the modal loop is spinning.
2) BalWindow.download_list now logs how many entries were received and, when
the result is empty (the core download_list swallows errors and returns {}),
shows a warning to the user instead of failing silently. This makes any
future network/parse failure visible in the Electrum log and to the user.
Business logic in bal/core/* is unchanged.
* fix(gui): show the real download error reason in the warning popup
When 'Download List' fails, the core download_list returns {} and the cause
was only visible in the Electrum log (which is hard to capture). The GUI now
re-issues the same raw request when the result is empty and shows the actual
exception/reason in the warning popup (e.g. SSL error, timeout, empty server
response). Pure GUI-side diagnostics; bal/core/* logic unchanged.
* fix(gui): download will-executor list synchronously like the original
ROOT CAUSE: the original plugin's 'Download List' button called
Willexecutors.download_list() DIRECTLY on the GUI thread
(qt.py: WillExecutorWidget.download_list). The refactor instead routed the
button through BalWaitingDialog + TaskThread. Electrum's
Network.send_http_on_proxy behaves differently depending on the calling
thread, and on the user's setup the TaskThread path timed out ('No response
from the server'), while the original direct call worked fine.
FIX: WillExecutorWidget.download_list now performs the same direct,
synchronous download as the original, updates and saves the list, and shows a
warning only on genuine failure. The wizard download path (which the original
also ran via TaskThread) is left unchanged.
Compared against upstream original source (kaibot/bal-electrum-plugin):
send_request, handle_response, download_list core logic are byte-identical;
only the GUI call site is restored to the original behaviour.
* diag(gui): detailed download diagnostics + hardcoded-URL fallback
The will-executor download still times out on the user's setup even with the
direct (original-style) GUI-thread call, and the URL/request are byte-identical
to the working original. To pinpoint the real cause, the Download List button
now:
- logs whether a Network instance is present;
- tries the configured WELIST_SERVER URL AND falls back to the original
hardcoded https://welist.bitcoin-after.life/ endpoint (so a stale/bad config
value can't break it);
- shows the EXACT URL(s) tried and the precise exception per attempt in the
warning popup instead of a generic timeout message.
bal/core networking remains unchanged.
* diag(gui): add direct-HTTPS control probe to download diagnostics
When the Electrum-network download fails, also run a plain urllib HTTPS GET
(bypassing Electrum's Network/proxy layer) and show its result in the popup.
This distinguishes a real connectivity/DNS/firewall problem from an
Electrum-network-state problem, so we can finally pinpoint why the request
times out only in this build.
* fix(gui): unify wizard + button download on one synchronous path with diagnostics
The 'No response from the server (timeout?)' popup was coming from the WIZARD
download path in window.py (BalWaitingDialog + TaskThread), which was never
switched to the original direct call - only the list button had been.
Both paths now share BalWindow.fetch_will_executors_list(): a direct,
synchronous GUI-thread download (like the original), trying the configured
server then the hardcoded fallback, with full diagnostics (exact URL/error per
attempt + a direct-HTTPS control probe) shown in the failure popup.
This both fixes the wizard timeout and guarantees the same diagnostic popup
('Details (via Electrum network)' + 'Direct connection test') regardless of
which UI entry point is used.
* fix(gui): clean up will-executor download (waiting dialog + simple message)
Root cause of the 'download not working' reports was environmental (the user's
network/ISP was resetting the connection to the IPv6/IPv4 host; a VPN fixes
it), NOT a plugin bug. Final cleanup of the diagnostic code:
- download_list (button + wizard) again uses BalWaitingDialog + TaskThread so
the GUI is not frozen and shows a 'Downloading will-executors list...' dialog.
- Keep the configured + hardcoded-fallback server URLs and detailed per-attempt
diagnostics, but write them to the Electrum log only.
- On failure the user now sees a simple English message explaining it is most
likely a connection/firewall issue (a VPN often helps), instead of a technical
timeout/exception dump.
- Removed the urllib control probe from the user-facing popup.
bal/core networking unchanged.
---------
Co-authored-by: GenSpark AI Developer <ai@genspark.dev>
This commit is contained in:
committed by
steal
parent
4711f7de62
commit
c8a9cbfc0a
109
tests/gui_fixes_test.py
Normal file
109
tests/gui_fixes_test.py
Normal file
@@ -0,0 +1,109 @@
|
||||
"""Regression tests for the GUI window/lifecycle fixes (B1-B10).
|
||||
|
||||
These tests need a QApplication but run head-less under
|
||||
``QT_QPA_PLATFORM=offscreen``. They check the *behaviour* of the centralized
|
||||
window helpers and assert that the known bug patterns are gone, without trying
|
||||
to drive a full Electrum session.
|
||||
|
||||
Usage:
|
||||
QT_QPA_PLATFORM=offscreen PYTHONPATH=<electrum-src> \
|
||||
python3 tests/gui_fixes_test.py <PKG>
|
||||
where <PKG> is e.g. electrum.plugins.bal
|
||||
"""
|
||||
|
||||
import ast
|
||||
import importlib
|
||||
import inspect
|
||||
import sys
|
||||
|
||||
|
||||
def _active_source_without_strings(module) -> str:
|
||||
"""Return module source with docstrings/strings removed.
|
||||
|
||||
Lets us assert a token is absent from *executable* code even if it still
|
||||
appears inside an explanatory docstring/comment.
|
||||
"""
|
||||
src = inspect.getsource(module)
|
||||
tree = ast.parse(src)
|
||||
# collect string-constant spans to drop
|
||||
class _S(ast.NodeVisitor):
|
||||
def __init__(self):
|
||||
self.spans = []
|
||||
def visit_Constant(self, node):
|
||||
if isinstance(node.value, str) and hasattr(node, "end_lineno"):
|
||||
self.spans.append((node.lineno, node.end_lineno))
|
||||
self.generic_visit(node)
|
||||
s = _S(); s.visit(tree)
|
||||
drop = set()
|
||||
for a, b in s.spans:
|
||||
drop.update(range(a, b + 1))
|
||||
lines = src.splitlines()
|
||||
kept = [ln for i, ln in enumerate(lines, start=1)
|
||||
if i not in drop and not ln.lstrip().startswith("#")]
|
||||
return "\n".join(kept)
|
||||
|
||||
|
||||
def main(pkg: str) -> int:
|
||||
from PyQt6.QtWidgets import QApplication, QDialog, QWidget
|
||||
app = QApplication.instance() or QApplication(sys.argv)
|
||||
|
||||
wu = importlib.import_module(pkg + ".gui.qt.window_utils")
|
||||
|
||||
# top_level_of: returns the top-level container of a child widget
|
||||
w = QWidget(); child = QWidget(w)
|
||||
assert wu.top_level_of(child) is w
|
||||
assert wu.top_level_of(None) is None
|
||||
print("[OK] top_level_of")
|
||||
|
||||
# bring_to_front / stop_thread must never raise on edge inputs
|
||||
wu.bring_to_front(QDialog())
|
||||
wu.stop_thread(None)
|
||||
print("[OK] bring_to_front / stop_thread(None)")
|
||||
|
||||
# _window_key: stable and unique per window
|
||||
plugin_mod = importlib.import_module(pkg + ".gui.qt.plugin")
|
||||
a, b = QWidget(), QWidget()
|
||||
assert plugin_mod._window_key(a) == plugin_mod._window_key(a)
|
||||
assert plugin_mod._window_key(a) != plugin_mod._window_key(b)
|
||||
print("[OK] _window_key stable & unique")
|
||||
|
||||
# B3/B4: no winId bound-method key, no 'restart Electrum' surrender in
|
||||
# *executable* code (docstrings explaining the old behaviour are allowed).
|
||||
active = _active_source_without_strings(plugin_mod)
|
||||
assert "winId" not in active, "winId still used in executable code"
|
||||
print("[OK] no winId in executable code")
|
||||
|
||||
win_mod = importlib.import_module(pkg + ".gui.qt.window")
|
||||
active_win = _active_source_without_strings(win_mod)
|
||||
assert "restart Electrum" not in active_win
|
||||
print("[OK] no 'restart Electrum' surrender in window.py code")
|
||||
|
||||
# B1: BalDialog must not shadow QWidget.parent() with an attribute
|
||||
dialogs_mod = importlib.import_module(pkg + ".gui.qt.dialogs")
|
||||
dsrc = inspect.getsource(dialogs_mod)
|
||||
assert "self.parent =" not in dsrc, "self.parent assignment still present"
|
||||
print("[OK] no self.parent shadowing in dialogs.py")
|
||||
|
||||
# REGRESSION: BalDialog.closeEvent / hideEvent must NOT stop the task
|
||||
# thread. Electrum's TaskThread.on_done calls cb_done (often self.accept,
|
||||
# which closes the dialog) BEFORE cb_result (on_success, e.g. updating the
|
||||
# will-executor list). If the base closeEvent stopped/joined the thread,
|
||||
# the auto-close from accept() would tear the thread down before
|
||||
# on_success ran and the downloaded list would be silently dropped.
|
||||
close_src = inspect.getsource(dialogs_mod.BalDialog.closeEvent)
|
||||
hide_src = inspect.getsource(dialogs_mod.BalDialog.hideEvent)
|
||||
assert "stop_thread" not in close_src, (
|
||||
"BalDialog.closeEvent must not stop the thread (drops download result)")
|
||||
assert "stop_thread" not in hide_src, (
|
||||
"BalDialog.hideEvent must not stop the thread (drops download result)")
|
||||
print("[OK] BalDialog.closeEvent/hideEvent do not kill the task thread")
|
||||
|
||||
print(f"\n[OK] all GUI-fix checks passed for package {pkg!r}")
|
||||
return 0
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
if len(sys.argv) != 2:
|
||||
print(__doc__)
|
||||
sys.exit(2)
|
||||
sys.exit(main(sys.argv[1]))
|
||||
Reference in New Issue
Block a user