mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-09-28 04:54:13 +02:00
ispyisail
8623dd4c6f
openAndAddProject() shows BackupDialog as a stack object parented to the editor and exec()s it; every QET::QetMessageBox does the same. exec() runs a nested event loop, and closing the editor during it turns WA_DeleteOnClose into a deleteLater() that the nested loop processes: ~QWidget() deletes the editor's children, the stack-allocated dialog among them, and the process aborts. Reported on macOS, where File > Quit lives in the application menu and stays usable while the backup question is up. The close is now refused while any modal widget is active, and the dialog is raised so the refused quit is not silent. It is done in QETMainWindow::event() rather than in closeEvent(), because QETDiagramEditor::closeEvent() starts closing projects before it decides whether to accept. That covers the diagram and title-block editors; QETElementEditor is a plain QMainWindow, so its closeEvent() calls the same helper before canClose(), which itself opens a modal. QETApp::quitQET() needs nothing: closeEveryEditor() goes through each editor's close(), and quitQET() already only quits when every close succeeded. Rejected alternatives, both suggested on the issue: - Giving the dialog no parent stops the abort but not the deletion. One caller of openAndAddProject() is the editor's own constructor, which goes on to open the next file and call slot_updateActions() on this -- a loud abort would become a silent use-after-free. - Guarding only QETApp::closeEveryEditor(), which I first recommended on the issue, misses the reported route entirely: File > Quit is connected to QETDiagramEditor::close(), not to quitQET(). Verified on Linux, where there is nothing to click (the menu bar belongs to the blocked window, and Qt ignores window-manager close requests for it), by calling close() from gdb while the dialog's loop was running -- both QETApp::quitQET() and QWidget::close() on the editor. Unfixed, both abort with "free(): invalid size" in QObjectPrivate::deleteChildren() under ~QETDiagramEditor(), matching the report frame for frame; fixed, close() returns false, the editor and the dialog stay up, and after answering the dialog Ctrl+Q exits normally. The element-editor guard is the same helper but was not exercised separately. tests/modal-quit-regression/ turns that into a gate: it breaks on QDialog::exec(), interrupts inside the nested loop, calls quitQET() and checks the process survives. It matches no window titles (translated) and no window ids, runs on the offscreen platform, and needs only gdb with Python. Checked both ways: exit 1 with the backtrace above on a build without this change, exit 0 with it. ctest 8/8. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>