Regression: Dragging an ID from the Outliner of a window cannot be dropped in another window #93685

New Issue

Jonathan Sedlak · 2021-12-05T05:15:22+01:00

Jonathan Sedlak commented

2021-12-05 05:15:22 +01:00

System Information
Operating system: Windows 10
Graphics card: EVGA 3090 FTW3

Blender Version
Broken: 2.90 (introduced in 7dbfc864e6)
Worked: 2.83

Short description of error
When I have two windows open, I can't drag objects from, for example, the outliner to geometry nodes editor in another window.
If I open geometry nodes editor in the same window, I can drag an object from the outliner to the editor and get an object info node no problem.

Exact steps for others to reproduce the error

Open the default blend file.
Add geometry nodes modifier to the default cube.
Open a new window, change it to geometry nodes editor.
Create a new mesh, whatever you'd like.
Select your new mesh from the outliner and drag it to your other window with geometry nodes editor.
Blender doesn't know what to do and fails to create object info node.
drag_and_drop_on_another_window.blend

**System Information** Operating system: Windows 10 Graphics card: EVGA 3090 FTW3 **Blender Version** Broken: 2.90 (introduced in 7dbfc864e6) Worked: 2.83 **Short description of error** When I have two windows open, I can't drag objects from, for example, the outliner to geometry nodes editor in another window. If I open geometry nodes editor in the same window, I can drag an object from the outliner to the editor and get an object info node no problem. **Exact steps for others to reproduce the error** - Open the default blend file. - Add geometry nodes modifier to the default cube. - Open a new window, change it to geometry nodes editor. - Create a new mesh, whatever you'd like. - Select your new mesh from the outliner and drag it to your other window with geometry nodes editor. - Blender doesn't know what to do and fails to create object info node. [drag_and_drop_on_another_window.blend](https://archive.blender.org/developer/F12727245/drag_and_drop_on_another_window.blend)

Jonathan Sedlak commented

2021-12-05 05:15:22 +01:00

Added subscriber: @jonsedlak222

Germano Cavalcante commented

2021-12-10 15:13:29 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2021-12-10 15:13:29 +01:00

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'

Germano Cavalcante commented

2021-12-10 15:13:29 +01:00

Thanks for the report, I can confirm the problem on windows.

But this is not just an outliner or geometry nodes problem, it affects any drag and drop operation from one window to another window.

What happens is that drag events have the mouse captured for the window.
This means that only the window where the mouse button was pressed is the one that receives mouse events.

I'm not sure why it works like that, it must have some benefit.
If the behavior is different on Linux it deserves more attention.

Thanks for the report, I can confirm the problem on windows. But this is not just an outliner or geometry nodes problem, it affects any drag and drop operation from one window to another window. What happens is that drag events have the mouse captured for the window. This means that only the window where the mouse button was pressed is the one that receives mouse events. I'm not sure why it works like that, it must have some benefit. If the behavior is different on Linux it deserves more attention.

Germano Cavalcante changed title from ~~Draggin Object info from outliner in one blender window to geometry nodes editor in another window~~ to Dragging an ID from a window cannot be dropped on another window

2021-12-10 15:15:30 +01:00

Pratik Borhade commented

2022-12-06 06:48:34 +01:00

Added subscriber: @PratikPB2123

Pratik Borhade commented

2022-12-06 06:48:34 +01:00

I can confirm this. Maybe this would be useful in multi-monitor setup.

drag events have the mouse captured for the window.
This means that only the window where the mouse button was pressed is the one that receives mouse events.

Looking at the current behavior as @mano-wii said, this report sounds more about the request to support dragging between multiple windows than a bug in blender.
I think we can close this report.

I can confirm this. Maybe this would be useful in multi-monitor setup. > drag events have the mouse captured for the window. > This means that only the window where the mouse button was pressed is the one that receives mouse events. Looking at the current behavior as @mano-wii said, this report sounds more about the request to support dragging between multiple windows than a bug in blender. I think we can close this report.

Germano Cavalcante commented

2022-12-06 16:09:13 +01:00

Changed status from 'Needs Developer To Reproduce' to: 'Confirmed'

Germano Cavalcante commented

2022-12-06 16:09:13 +01:00

Added subscriber: @natecraddock

Germano Cavalcante commented

2022-12-06 16:09:14 +01:00

Upon further investigation, this is indeed a problem with DragDrop from the Outliner (and perhaps from a few others editors).
Even with a captured window, events are still sent to other windows as long as the window manager has no modal operators running.
But the OUTLINER_OT_item_drag_drop operator invokes the VIEW2D_OT_edge_pan modal operator and thus, events for other windows are no longer dispatched (See wm_event_cursor_other_windows).

If we remove the VIEW2D_OT_edge_pan operator call, the problem is solved:

diff --git a/source/blender/editors/space_outliner/outliner_dragdrop.cc b/source/blender/editors/space_outliner/outliner_dragdrop.cc
index 3b07c6da5fa..bc546e1a47d 100644
--- a/source/blender/editors/space_outliner/outliner_dragdrop.cc
+++ b/source/blender/editors/space_outliner/outliner_dragdrop.cc
@@ -1432,17 +1432,6 @@ static int outliner_item_drag_drop_invoke(bContext *C, wmOperator * /*op*/, cons
     return OPERATOR_CANCELLED | OPERATOR_PASS_THROUGH;
   }
 
-  /* Scroll the view when dragging near edges, but not
-   * when the drag goes too far outside the region. */
-  {
-    wmOperatorType *ot = WM_operatortype_find("VIEW2D_OT_edge_pan", true);
-    PointerRNA op_ptr;
-    WM_operator_properties_create_ptr(&op_ptr, ot);
-    RNA_float_set(&op_ptr, "outside_padding", OUTLINER_DRAG_SCOLL_OUTSIDE_PAD);
-    WM_operator_name_call_ptr(C, ot, WM_OP_INVOKE_DEFAULT, &op_ptr, event);
-    WM_operator_properties_free(&op_ptr);
-  }
-
   const bool use_datastack_drag = ELEM(tselem->type,
                                        TSE_MODIFIER,
                                        TSE_MODIFIER_BASE,

So this problem was introduced in 7dbfc864e6 (Blender 2.90).
It's a regression!

Cc. @natecraddock

Upon further investigation, this is indeed a problem with DragDrop from the Outliner (and perhaps from a few others editors). Even with a captured window, events are still sent to other windows as long as the window manager has no modal operators running. But the `OUTLINER_OT_item_drag_drop` operator invokes the `VIEW2D_OT_edge_pan` modal operator and thus, events for other windows are no longer dispatched (See `wm_event_cursor_other_windows`). If we remove the `VIEW2D_OT_edge_pan` operator call, the problem is solved: ``` diff --git a/source/blender/editors/space_outliner/outliner_dragdrop.cc b/source/blender/editors/space_outliner/outliner_dragdrop.cc index 3b07c6da5fa..bc546e1a47d 100644 --- a/source/blender/editors/space_outliner/outliner_dragdrop.cc +++ b/source/blender/editors/space_outliner/outliner_dragdrop.cc @@ -1432,17 +1432,6 @@ static int outliner_item_drag_drop_invoke(bContext *C, wmOperator * /*op*/, cons return OPERATOR_CANCELLED | OPERATOR_PASS_THROUGH; } - /* Scroll the view when dragging near edges, but not - * when the drag goes too far outside the region. */ - { - wmOperatorType *ot = WM_operatortype_find("VIEW2D_OT_edge_pan", true); - PointerRNA op_ptr; - WM_operator_properties_create_ptr(&op_ptr, ot); - RNA_float_set(&op_ptr, "outside_padding", OUTLINER_DRAG_SCOLL_OUTSIDE_PAD); - WM_operator_name_call_ptr(C, ot, WM_OP_INVOKE_DEFAULT, &op_ptr, event); - WM_operator_properties_free(&op_ptr); - } - const bool use_datastack_drag = ELEM(tselem->type, TSE_MODIFIER, TSE_MODIFIER_BASE, ``` So this problem was introduced in 7dbfc864e6 (Blender 2.90). It's a regression! Cc. @natecraddock

Germano Cavalcante changed title from ~~Dragging an ID from a window cannot be dropped on another window~~ to Regression: Dragging an ID from the Outliner of a window cannot be dropped in another window

2022-12-06 16:12:05 +01:00

Thomas Dinges commented

2023-01-13 15:46:27 +01:00

Added subscribers: @JulianEisel, @ThomasDinges

Thomas Dinges commented

2023-01-13 15:46:27 +01:00

@natecraddock Hey, are you still around to take a look at Germanos patch above? Alternatively can I ask you @JulianEisel to take a look please? Since a patch is available it would be good to fix this high priority bug.

Nathan Craddock commented

2023-01-13 20:54:59 +01:00

Hi @ThomasDinges, I pay attention to development from afar, but don't have the time to help sadly

Thomas Dinges commented

2023-01-13 21:37:58 +01:00

@natecraddock I understand, thanks for getting back to me anyway! :)

Harley Acheson commented

2023-01-14 02:48:10 +01:00

Added subscriber: @Harley

Harley Acheson commented

2023-01-14 02:48:10 +01:00

@mano-wii - If we remove the VIEW2D_OT_edge_pan operator call, the problem is solved...

Or we could relax that "Let's skip windows having modal handlers now" a bit in wm_event_cursor_other_windows

diff --git a/source/blender/windowmanager/intern/wm_event_system.cc b/source/blender/windowmanager/intern/wm_event_system.cc
index 14812c4335dc..5ffe8b3f9cd4 100644
--- a/source/blender/windowmanager/intern/wm_event_system.cc
+++ b/source/blender/windowmanager/intern/wm_event_system.cc
@@ -5026,45 +5026,46 @@ static void attach_ndof_data(wmEvent *event, const GHOST_TEventNDOFMotionData *g
 static wmWindow *wm_event_cursor_other_windows(wmWindowManager *wm, wmWindow *win, wmEvent *event)
 {
   /* If GHOST doesn't support window positioning, don't use this feature at all. */
   const static int8_t supports_window_position = GHOST_SupportsWindowPosition();
   if (!supports_window_position) {
     return nullptr;
   }
 
   if (wm->windows.first == wm->windows.last) {
     return nullptr;
   }
 
   /* In order to use window size and mouse position (pixels), we have to use a WM function. */
 
   /* Check if outside, include top window bar. */
   int event_xy[2] = {UNPACK2(event->xy)};
   if (event_xy[0] < 0 || event_xy[1] < 0 || event_xy[0] > WM_window_pixels_x(win) ||
       event_xy[1] > WM_window_pixels_y(win) + 30) {
     /* Let's skip windows having modal handlers now. */
     /* Potential XXX ugly... I wouldn't have added a `modalhandlers` list
      * (introduced in rev 23331, ton). */
     LISTBASE_FOREACH (wmEventHandler *, handler, &win->modalhandlers) {
-      if (ELEM(handler->type, WM_HANDLER_TYPE_UI, WM_HANDLER_TYPE_OP)) {
+      if (ELEM(handler->type, WM_HANDLER_TYPE_UI, WM_HANDLER_TYPE_OP) &&
+          handler->flag & WM_HANDLER_BLOCKING) {
         return nullptr;
       }
     }
 
     wmWindow *win_other = WM_window_find_under_cursor(win, event_xy, event_xy);
     if (win_other && win_other != win) {
       copy_v2_v2_int(event->xy, event_xy);
       return win_other;
     }
   }
   return nullptr;
 }
 
 static bool wm_event_is_double_click(const wmEvent *event)
 {
   if ((event->type == event->prev_type) && (event->prev_val == KM_RELEASE) &&
       (event->val == KM_PRESS)) {
     if (ISMOUSE_BUTTON(event->type) && WM_event_drag_test(event, event->prev_press_xy)) {
       /* Pass. */
     }
     else {
       if ((PIL_check_seconds_timer() - event->prev_press_time) * 1000 < U.dbl_click_time) {

Old code though, not sure I want to touch it. LOL

> @mano-wii - If we remove the `VIEW2D_OT_edge_pan` operator call, the problem is solved... Or we could relax that "Let's skip windows having modal handlers now" a bit in `wm_event_cursor_other_windows` ``` diff --git a/source/blender/windowmanager/intern/wm_event_system.cc b/source/blender/windowmanager/intern/wm_event_system.cc index 14812c4335dc..5ffe8b3f9cd4 100644 --- a/source/blender/windowmanager/intern/wm_event_system.cc +++ b/source/blender/windowmanager/intern/wm_event_system.cc @@ -5026,45 +5026,46 @@ static void attach_ndof_data(wmEvent *event, const GHOST_TEventNDOFMotionData *g static wmWindow *wm_event_cursor_other_windows(wmWindowManager *wm, wmWindow *win, wmEvent *event) { /* If GHOST doesn't support window positioning, don't use this feature at all. */ const static int8_t supports_window_position = GHOST_SupportsWindowPosition(); if (!supports_window_position) { return nullptr; } if (wm->windows.first == wm->windows.last) { return nullptr; } /* In order to use window size and mouse position (pixels), we have to use a WM function. */ /* Check if outside, include top window bar. */ int event_xy[2] = {UNPACK2(event->xy)}; if (event_xy[0] < 0 || event_xy[1] < 0 || event_xy[0] > WM_window_pixels_x(win) || event_xy[1] > WM_window_pixels_y(win) + 30) { /* Let's skip windows having modal handlers now. */ /* Potential XXX ugly... I wouldn't have added a `modalhandlers` list * (introduced in rev 23331, ton). */ LISTBASE_FOREACH (wmEventHandler *, handler, &win->modalhandlers) { - if (ELEM(handler->type, WM_HANDLER_TYPE_UI, WM_HANDLER_TYPE_OP)) { + if (ELEM(handler->type, WM_HANDLER_TYPE_UI, WM_HANDLER_TYPE_OP) && + handler->flag & WM_HANDLER_BLOCKING) { return nullptr; } } wmWindow *win_other = WM_window_find_under_cursor(win, event_xy, event_xy); if (win_other && win_other != win) { copy_v2_v2_int(event->xy, event_xy); return win_other; } } return nullptr; } static bool wm_event_is_double_click(const wmEvent *event) { if ((event->type == event->prev_type) && (event->prev_val == KM_RELEASE) && (event->val == KM_PRESS)) { if (ISMOUSE_BUTTON(event->type) && WM_event_drag_test(event, event->prev_press_xy)) { /* Pass. */ } else { if ((PIL_check_seconds_timer() - event->prev_press_time) * 1000 < U.dbl_click_time) { ``` Old code though, not sure I want to touch it. LOL

Germano Cavalcante commented

2023-01-27 22:10:53 +01:00

I went after more context for that code.
It was from a bug fix described at https://lists.blender.org/pipermail/bf-blender-cvs/2010-January/025570.html

From what I can tell, some modal operators (which allow the cursor to leave the region) need to capture all events for themselves.
Otherwise the other window's interface will interact and some events may be lost.

If we remove that code, we could notice the problem with for example the Measure Tool.
In this case, if we drag the ruler to another window, the action of releasing the {key LMB} may be lost for the main window.

Checking WM_HANDLER_BLOCKING doesn't seem to solve it.
Maybe implementing a new flag and setting it to VIEW2D_OT_edge_pan would be a solution?

I went after more context for that code. It was from a bug fix described at https://lists.blender.org/pipermail/bf-blender-cvs/2010-January/025570.html From what I can tell, some modal operators (which allow the cursor to leave the region) need to capture all events for themselves. Otherwise the other window's interface will interact and some events may be lost. If we remove that code, we could notice the problem with for example the Measure Tool. In this case, if we drag the ruler to another window, the action of releasing the {key LMB} may be lost for the main window. Checking `WM_HANDLER_BLOCKING` doesn't seem to solve it. Maybe implementing a new flag and setting it to `VIEW2D_OT_edge_pan` would be a solution?

Harley Acheson commented

2023-01-30 18:58:05 +01:00

@mano-wii - Maybe implementing a new flag and setting it to VIEW2D_OT_edge_pan would be a solution?

That might be a great solution. But there is another thought that might be simpler. Has a very small downside, but would need a bit more investigation. Right now the issue is that VIEW2D_OT_edge_pan is started as soon as you start dragging and stays running even when you drag it out of the window. We could let that operator finish when it enters a new window:

diff --git a/source/blender/editors/interface/view2d_ops.cc b/source/blender/editors/interface/view2d_ops.cc
index b76f5f1e49fd..62ee9fd6a0b5 100644
--- a/source/blender/editors/interface/view2d_ops.cc
+++ b/source/blender/editors/interface/view2d_ops.cc
@@ -343,11 +343,15 @@ static int view_edge_pan_invoke(bContext *C, wmOperator *op, const wmEvent * /*e
 
 static int view_edge_pan_modal(bContext *C, wmOperator *op, const wmEvent *event)
 {
   View2DEdgePanData *vpd = static_cast<View2DEdgePanData *>(op->customdata);
 
-  if (event->val == KM_RELEASE || event->type == EVT_ESCKEY) {
+  wmWindow *source_win = CTX_wm_window(C);
+  int r_mval[2];
+  wmWindow *target_win = WM_window_find_under_cursor(source_win, event->xy, &r_mval[0]);
+
+  if (event->val == KM_RELEASE || event->type == EVT_ESCKEY || source_win != target_win) {
     vpd->v2d->flag &= ~V2D_IS_NAVIGATING;
     MEM_SAFE_FREE(op->customdata);
     return (OPERATOR_FINISHED | OPERATOR_PASS_THROUGH);
   }

The small downside is pretty small. Right now you can edge pan, drag out of the window to another, come back to the first, do more edge panning. With above you can't continuing to edge pan after you've dragged out that far. Not sure anyone would care.

The further investigation is that after a dragand drop of an object from one window to another you can sometimes be left with a "stopsign" mouse cursor. Happens enough to know it is a thing but I'm not sure of the circumstances and cause of it. Regular and modal cursors are set per-window though, so probably an easy thing to track down if we want to go this route.

> @mano-wii - Maybe implementing a new flag and setting it to `VIEW2D_OT_edge_pan` would be a solution? That might be a great solution. But there is another thought that might be simpler. Has a very small downside, but would need a bit more investigation. Right now the issue is that VIEW2D_OT_edge_pan is started as soon as you start dragging and stays running even when you drag it out of the window. We could let that operator *finish* when it enters a **new** window: ``` diff --git a/source/blender/editors/interface/view2d_ops.cc b/source/blender/editors/interface/view2d_ops.cc index b76f5f1e49fd..62ee9fd6a0b5 100644 --- a/source/blender/editors/interface/view2d_ops.cc +++ b/source/blender/editors/interface/view2d_ops.cc @@ -343,11 +343,15 @@ static int view_edge_pan_invoke(bContext *C, wmOperator *op, const wmEvent * /*e static int view_edge_pan_modal(bContext *C, wmOperator *op, const wmEvent *event) { View2DEdgePanData *vpd = static_cast<View2DEdgePanData *>(op->customdata); - if (event->val == KM_RELEASE || event->type == EVT_ESCKEY) { + wmWindow *source_win = CTX_wm_window(C); + int r_mval[2]; + wmWindow *target_win = WM_window_find_under_cursor(source_win, event->xy, &r_mval[0]); + + if (event->val == KM_RELEASE || event->type == EVT_ESCKEY || source_win != target_win) { vpd->v2d->flag &= ~V2D_IS_NAVIGATING; MEM_SAFE_FREE(op->customdata); return (OPERATOR_FINISHED | OPERATOR_PASS_THROUGH); } ``` The small downside is pretty small. Right now you can edge pan, drag out of the window to another, come back to the first, do more edge panning. With above you can't continuing to edge pan after you've dragged out that far. Not sure anyone would care. The further investigation is that after a dragand drop of an object from one window to another you can sometimes be left with a "stopsign" mouse cursor. Happens enough to know it is a thing but I'm not sure of the circumstances and cause of it. Regular and modal cursors are set per-window though, so probably an easy thing to track down if we want to go this route.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Regression: Dragging an ID from the Outliner of a window cannot be dropped in another window #93685