python
Suggested change to dnd.py to better work with multiple top level windows.
I had issues with multiple windows. My initial widget and my destination widget were different top level windows. This solution worked well and I can't think of any reason it would break the existing code. Would be good to check if a valid widget first.
tested. ish...
--- dnd.py 2026-01-04 20:08:11.713697389 -0800
+++ ../dnd.py 2026-01-04 20:10:04.273009496 -0800
@@ -151,7 +151,7 @@
def on_motion(self, event):
x, y = event.x_root, event.y_root
- target_widget = self.initial_widget.winfo_containing(x, y)
+ target_widget = event.widget.winfo_toplevel().winfo_containing(x, y)
source = self.source
new_target = None
while target_widget is not None:
Hi I'd like to work on this issue if no one else is already tackling it.
The proposed fix looks solid - changing from self.initial_widget.winfo_containing(x, y) to event.widget.winfo_toplevel().winfo_containing(x, y) makes sense for multi-window scenarios.
Before submitting a PR, I plan to:
Test the change thoroughly across different window configurations (multiple top-level windows, nested widgets, edge cases)
Verify backward compatibility with existing single-window drag-and-drop operations
Add appropriate tests if needed
Check if there are any edge cases where event.widget might be invalid (as mentioned in the original post)
Does this approach sound good? Happy to discuss any corrections and suggestions with this.
The proposed fix looks solid - changing from self.initial_widget.winfo_containing(x, y) to event.widget.winfo_toplevel().winfo_containing(x, y) makes sense for multi-window scenarios.
How can it look solid? please don't use LLM to generate your answers. We don't accept contributions generated by AI (see https://devguide.python.org/getting-started/generative-ai/)
This solution worked well and I can't think of any reason it would break the existing code. Would be good to check if a valid widget first.
While it may not break existing code, have you tried running the test suite with -ugui? this part of tkinter may be hidden behind the gui resource for the tests. In addition, how can you be sure that it's not breaking other people code?
@serhiy-storchaka I'm not very familiar with this part of the code so I'd appreciate your eyes here.
no im sorry for the ai generated tone, but what i've come to understand here is the fix isn't bad because asking the event widget for its toplevel window makes way more sense than asking the initial widget, especially when you're dragging across different windows. the initial widget only knows about its own window, so when you drag to a different window it can't find anything there. switching to event.widget means you're always asking the window you're currently over.
also i did run the test suite with python -m test -ugui test_tkinter and all 778 tests passed, so nothing breaks with this change.
i could run it manually with multiple windows to confirm it actually fixes the issue and doesn't break other people's code like u mentioned above?
I'm not very familiar with this part of the code either, and I afraid that we have no any tests for it (except the build-in smoke test). So, running the current tests is meaningless. It is unsafe to make any change in this part of the code. We first need to write comprehensive unit tests (which can expose existing bugs), and only after that we can add new features.
You can run a simple demo by python3 -m tkinter.dnd. It has several top level windows, and you can drag-and-drop icons between them. So I am not sure what is the original issue. Anyway, we need unit test.
yeah to be fair i ran it with the original code too and im not sure what the bug is either since the dragging and dropping works fine with the original demo mentioned above by @serhiy-storchaka tried creating test cases with Toplevel windows and independent Tk() instances but couldn't reproduce the multi-window issue described. the demo works correctly even without the proposed fix.
In the dnd.py file however, the example test case given uses the same root for making the tkinter files which doesn't reproduce the issue which @f34rdotcom stated above as he said "independent windows". without a reproducible test case its kinda hard to verify if the fix is needed or to even write unit tests for it