Refuse to close an editor while a modal dialog is running (#904)

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>

sources/qetmainwindow.cpp

@@ -16,6 +16,7 @@
 	along with QElectroTech.  If not, see <http://www.gnu.org/licenses/>.
 */
 #include <QAction>
+#include <QApplication>
 #include <QWhatsThis>
 #include <QMenu>
 #include <QMenuBar>
@@ -290,6 +291,9 @@ void QETMainWindow::activateMenuBar() {
 }
 
 bool QETMainWindow::event(QEvent *e) {
+	if (e -> type() == QEvent::Close && refuseCloseWhileModal(e)) {
+		return(true);
+	}
 	if (e -> type() == QEvent::WindowStateChange) {
 		updateFullScreenAction();
 	} else if (first_activation_ && e -> type() == QEvent::WindowActivate) {
@@ -299,6 +303,44 @@ bool QETMainWindow::event(QEvent *e) {
 	return(QMainWindow::event(e));
 }
 
+/**
+	@brief QETMainWindow::refuseCloseWhileModal
+	Refuse to close an editor window while any modal dialog is running.
+
+	A modal dialog's exec() runs a nested event loop. If a window is closed
+	during it, the window's WA_DeleteOnClose turns into a deleteLater() that
+	the *nested* loop processes: the window is destroyed while code that
+	belongs to it -- often the very function that opened the dialog -- is
+	still on the stack. Most of QET's dialogs are stack objects parented to
+	the window (BackupDialog, and every QET::QetMessageBox), so ~QWidget()
+	then deletes a stack object and the process aborts (issue #904). Even a
+	dialog without a parent would only trade that abort for a silent
+	use-after-free in the caller.
+
+	Qt already ignores window-manager close requests for a window blocked by
+	a modal, so this is only reachable through close() called directly: the
+	File > Quit action, which macOS moves into the application menu where it
+	stays usable during a modal, and QETApp::quitQET() from the system tray.
+
+	Handled in event(), before closeEvent() runs, because the editors'
+	closeEvent() starts closing projects before it decides whether to accept.
+	The dialog is raised so a refused quit is not silent.
+
+	@param e : the QEvent::Close being delivered
+	@return true if the close was refused and must not be processed further
+*/
+bool QETMainWindow::refuseCloseWhileModal(QEvent *e)
+{
+	QWidget *modal = QApplication::activeModalWidget();
+	if (!modal) {
+		return(false);
+	}
+	modal -> raise();
+	modal -> activateWindow();
+	e -> ignore();
+	return(true);
+}
+
 /**
 	Base implementation of firstActivation (does nothing).
 */