mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-08-13 10:04:13 +02:00
4bd9b6b212
Bugtracker #323: crash changing a label's color, but only when confirmed via Enter -- clicking the dialog's own OK button with the mouse doesn't crash. Reported on Windows 11 and Debian, with "QObject::installEventFilter(): Cannot filter events for objects in a different thread" immediately before the segfault. Root cause: DynamicTextItemDelegate::createEditor()'s color case constructed a QColorDialog and returned it directly as the item view's editor widget for the color cell -- unlike every other case in this same function, which returns a small inline widget (QSpinBox, QComboBox, or, for the adjacent font case, a plain placeholder). A QColorDialog is not designed to be used this way: it is not one of the objectNames this delegate's own eventFilter() special-cases, so Enter is handled by the base QStyledItemDelegate::eventFilter() as an ordinary "commit and destroy this small editor" trigger -- racing the dialog's own internal OK-button accept/close path, which on Windows can hand off to the native color picker. Clicking OK with the mouse doesn't go through the same key-press path, which is why only Enter crashed. Verified structurally: an embedded QColorDialog editor is a *child* widget of the view's viewport rather than a proper top-level dialog (confirmed with a standalone Qt program driving the real delegate through QAbstractItemView::edit() -- searching QApplication's top-level widgets never found it, only a search of the viewport's children did), which is the same "used as something it isn't" pattern, just observed a different way. Fix: mirror the font case immediately above -- resolve the color via the static, blocking QColorDialog::getColor() inside createEditor(), and hand back a plain QWidget with the result stashed in two properties (mirroring the font case's "ok" property) for setModelData() to read. By the time the view processes any commit trigger, the "editor" is an inert placeholder with no dialog state left to race. Verified end-to-end with the same standalone program: creates the model item, triggers editing, finds the real (top-level, this time) QColorDialog, clicks its actual OK button, confirms the color lands on the placeholder's properties, sends the editor a synthetic Enter keypress (the exact trigger from the bug report), and confirms the final committed value in the model matches the picked color. Also confirmed a full Release build (333/333) with no new warnings.