Frontmatter
| id | 8019 |
| title | Bug: isWindowDragging flag stuck after external drop |
| state | Closed |
| labels | bugstaleai |
| assignees | tobiu |
| createdAt | Dec 4, 2025, 2:30 AM |
| updatedAt | Mar 17, 2026, 7:49 PM |
| githubUrl | https://github.com/neomjs/neo/issues/8019 |
| author | tobiu |
| commentsCount | 1 |
| parentIssue | 7918 |
| subIssues | [] |
| subIssuesCompleted | 0 |
| subIssuesTotal | 0 |
| blockedBy | [] |
| blocking | [] |
| closedAt | Mar 17, 2026, 7:49 PM |
Bug: isWindowDragging flag stuck after external drop
tobiu assigned to @tobiu on Dec 4, 2025, 2:30 AM
tobiu added parent issue #7918 on Dec 4, 2025, 2:30 AM
saschabuehrle referenced in commit
4f14985 - "fix: reset isWindowDragging flag on drag end (fixes #8019) on Mar 17, 2026, 10:42 AM
saschabuehrle cross-referenced by PR #9501 on Mar 17, 2026, 10:42 AM
tobiu closed this issue on Mar 17, 2026, 7:49 PM
When dragging a widget to create a popup,
#isWindowDraggingis set to true. If the window is dropped outside the main viewport, this flag is not reset. Consequently, closing the popup fails to restore the widget becauseonWindowDisconnectexits early when this flag is true.Proposed Fix: Investigate
Neo.draggable.container.SortZoneorNeo.main.addon.DragDropevents to detect the end of a window drag operation and explicitly reset#isWindowDragging.Context: The user mentioned
src/manager/Window.mjsas a "god view" window manager that is partially implemented. This might be the architectural solution to manage window states centrally instead of ad-hoc flags in controllers.