https://bugs.kde.org/show_bug.cgi?id=517996
--- Comment #1 from François Guerraz <[email protected]> --- Created attachment 190907 --> https://bugs.kde.org/attachment.cgi?id=190907&action=edit claude 4.6 suggested patch Claude 4.6 suggests the attached fix, with the following justification. IDK if it fixes the issue which was not reproducible, but it doesn't crash either, I'll let you judge. The fix has been implemented in `libnotificationmanager/fullscreentracker.cpp`. The two `connect()` calls were changed from direct connections to `Qt::QueuedConnection`: ```cpp connect(this, &TaskManager::TasksModel::activeTaskChanged, this, &FullscreenTracker::checkFullscreenFocused, Qt::QueuedConnection); connect(this, &TaskManager::TasksModel::dataChanged, this, &FullscreenTracker::checkFullscreenFocused, Qt::QueuedConnection); ``` This prevents `checkFullscreenFocused()` from firing synchronously during row-removal signal processing in the task model proxy chain. With direct connections, the handler would trigger a cascade: fullscreen state change → notification filter invalidation → new row insertions → QML delegate creation → data() calls back into the same proxy chain that was mid-removal — hitting stale/freed internal mappings (the `0xfefefefefefefefe` pattern). With queued connections, `checkFullscreenFocused()` is deferred until the event loop processes it, by which time all proxy models have finished updating their internal state. -- You are receiving this mail because: You are watching all bug changes.
