Cursor icon stuck in scroll mode #78698

New Issue

SABRI Salim · 2020-07-07T11:31:03+02:00

SABRI Salim commented

2020-07-07 11:31:03 +02:00

System Information
Operating system: Linux-5.4.0-7634-generic-x86_64-with-debian-bullseye-sid 64 Bits
Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 440.100

Blender Version
Broken: version: 2.90.0 Alpha, branch: master, commit date: 2020-07-06 20:39, hash: e20171e59f
Worked: (newest version of Blender that worked as expected)

Short description of error
Cursor icon stuck in scroll mode when deleting modifier with 'X' shortcut

Exact steps for others to reproduce the error

Object with a modifier
Cursor over any number value in the modifier panel (the cursor will change icon to horizontal scroll icon).
press X to delete the modifier.
Cursor stuck in scroll icon.

**System Information** Operating system: Linux-5.4.0-7634-generic-x86_64-with-debian-bullseye-sid 64 Bits Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 440.100 **Blender Version** Broken: version: 2.90.0 Alpha, branch: master, commit date: 2020-07-06 20:39, hash: `e20171e59f` Worked: (newest version of Blender that worked as expected) **Short description of error** Cursor icon stuck in scroll mode when deleting modifier with 'X' shortcut **Exact steps for others to reproduce the error** Object with a modifier Cursor over any number value in the modifier panel (the cursor will change icon to horizontal scroll icon). press X to delete the modifier. Cursor stuck in scroll icon.

SABRI Salim commented

2020-07-07 11:31:03 +02:00

Added subscriber: @Dalkoom

blender-admin commented

2020-07-07 11:31:03 +02:00

#79527 was marked as duplicate of this issue

Richard Antalik commented

2020-07-08 07:21:56 +02:00

Added subscriber: @iss

Richard Antalik commented

2020-07-08 07:21:56 +02:00

Can't reproduce.

Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: Radeon RX550/550 Series ATI Technologies Inc. 4.5.13586 Core Profile Context 19.12.2 26.20.15002.61

Can't reproduce. Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: Radeon RX550/550 Series ATI Technologies Inc. 4.5.13586 Core Profile Context 19.12.2 26.20.15002.61

SABRI Salim commented

2020-07-08 17:37:58 +02:00

Steps to reproduce the error with : X to delete or Ctrl+A to Apply modifier

Steps to reproduce the error with : X to delete or Ctrl+A to Apply modifier ![Peek 2020-07-08 16-26.gif](https://archive.blender.org/developer/F8678524/Peek_2020-07-08_16-26.gif)

Hans Goudey commented

2020-07-08 17:59:55 +02:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2020-07-08 17:59:55 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Hans Goudey commented

2020-07-08 17:59:55 +02:00

Wow, this is odd. You have to use the shortcuts very quickly after using a number / slider button, and then the cursor isn't reset.

I'm not quite sure where to start here. I expect it's something about the panel (and button) being removed on the same redraw as the button would normally become inactive.

Wow, this is odd. You have to use the shortcuts *very* quickly after using a number / slider button, and then the cursor isn't reset. I'm not quite sure where to start here. I expect it's something about the panel (and button) being removed on the same redraw as the button would normally become inactive.

Richard Antalik commented

2020-08-05 05:54:44 +02:00

Added subscriber: @Eary

Hans Goudey commented

2020-08-05 22:10:14 +02:00

Added subscriber: @JulianEisel

Hans Goudey commented

2020-08-05 22:10:14 +02:00

Indeed, the issue is that the button doesn't run its exit handler because it's removed instead of having the button move away from it.

Although a simple solution would be resetting the cursor from the modifier delete operator, I don't like the idea of that.

This diff mostly fixes the problem by resetting the cursor whenever there isn't an active button:

diff --git a/source/blender/editors/interface/interface_handlers.c b/source/blender/editors/interface/interface_handlers.c
index 4944e29fcec..7e20e473051 100644
--- a/source/blender/editors/interface/interface_handlers.c
+++ b/source/blender/editors/interface/interface_handlers.c
@@ -8478,7 +8478,7 @@ static uiBut *ui_but_find_open_event(ARegion *region, const wmEvent *event)
 
 static int ui_handle_button_over(bContext *C, const wmEvent *event, ARegion *region)
 {
-  uiBut *but;
+  uiBut *but = NULL;
 
   if (event->type == MOUSEMOVE) {
     but = ui_but_find_mouse_over(region, event);
@@ -8499,6 +8499,10 @@ static int ui_handle_button_over(bContext *C, const wmEvent *event, ARegion *reg
     }
   }
 
+  if (but == NULL) {
+    WM_cursor_modal_restore(CTX_wm_window(C));
+  }
+
   return WM_UI_HANDLER_CONTINUE;
 }

But, as you might expect, it resets the cursor too much. However, that's actually because of the UI handlers for all of the other spaces, as seen below:

SET (Area Type: Buttons) (Region: 0)
RESTORE (Area: Outliner) (Region: 1)
RESTORE (Area: Outliner) (Region: 0)
RESTORE (Area: Action) (Region: 1)
RESTORE (Area: View3D) (Region: 12)
RESTORE (Area: View3D) (Region: 1)
RESTORE (Area: View3D) (Region: 5)
RESTORE (Area: View3D) (Region: 4)

This leads me to the question: Why is the handler even running for spacetypes that my mouse isn't even in? That doesn't seem necessary to me.
Anyway, I wonder what @JulianEisel thinks about this.

Indeed, the issue is that the button doesn't run its `exit` handler because it's removed instead of having the button move away from it. Although a simple solution would be resetting the cursor from the modifier delete operator, I don't like the idea of that. This diff mostly fixes the problem by resetting the cursor whenever there isn't an active button: ``` diff --git a/source/blender/editors/interface/interface_handlers.c b/source/blender/editors/interface/interface_handlers.c index 4944e29fcec..7e20e473051 100644 --- a/source/blender/editors/interface/interface_handlers.c +++ b/source/blender/editors/interface/interface_handlers.c @@ -8478,7 +8478,7 @@ static uiBut *ui_but_find_open_event(ARegion *region, const wmEvent *event) static int ui_handle_button_over(bContext *C, const wmEvent *event, ARegion *region) { - uiBut *but; + uiBut *but = NULL; if (event->type == MOUSEMOVE) { but = ui_but_find_mouse_over(region, event); @@ -8499,6 +8499,10 @@ static int ui_handle_button_over(bContext *C, const wmEvent *event, ARegion *reg } } + if (but == NULL) { + WM_cursor_modal_restore(CTX_wm_window(C)); + } + return WM_UI_HANDLER_CONTINUE; } ``` But, as you might expect, it resets the cursor **too** much. However, that's actually because of the UI handlers for all of the other spaces, as seen below: ``` SET (Area Type: Buttons) (Region: 0) RESTORE (Area: Outliner) (Region: 1) RESTORE (Area: Outliner) (Region: 0) RESTORE (Area: Action) (Region: 1) RESTORE (Area: View3D) (Region: 12) RESTORE (Area: View3D) (Region: 1) RESTORE (Area: View3D) (Region: 5) RESTORE (Area: View3D) (Region: 4) ``` This leads me to the question: Why is the handler even running for spacetypes that my mouse isn't even in? That doesn't seem necessary to me. Anyway, I wonder what @JulianEisel thinks about this.

Julian Eisel commented

2020-08-05 22:58:21 +02:00

The active button should be properly exited when the block gets removed. The panel removal code actually does the block removal just fine, it just needs the context to properly exit the button. I.e. I'd propose the following fix:

diff --git a/source/blender/editors/interface/interface_panel.c b/source/blender/editors/interface/interface_panel.c
index dd3074d6258..799a3b7fd5e 100644
--- a/source/blender/editors/interface/interface_panel.c
+++ b/source/blender/editors/interface/interface_panel.c
@@ -321,7 +321,7 @@ void UI_list_panel_unique_str(Panel *panel, char *r_name)
  * Remove the #uiBlock corresponding to a panel. The lookup is needed because panels don't store
  * a reference to their corresponding #uiBlock.
  */
-static void panel_free_block(ARegion *region, Panel *panel)
+static void panel_free_block(const bContext *C, ARegion *region, Panel *panel)
 {
   BLI_assert(panel->type);
 
@@ -334,7 +334,7 @@ static void panel_free_block(ARegion *region, Panel *panel)
   LISTBASE_FOREACH (uiBlock *, block, &region->uiblocks) {
     if (STREQ(block->name, block_name)) {
       BLI_remlink(&region->uiblocks, block);
-      UI_block_free(NULL, block);
+      UI_block_free(C, block);
       break; /* Only delete one block for this panel. */
     }
   }
@@ -347,15 +347,15 @@ static void panel_free_block(ARegion *region, Panel *panel)
  * \note The only panels that should need to be deleted at runtime are panels with the
  * #PNL_INSTANCED flag set.
  */
-static void panel_delete(ARegion *region, ListBase *panels, Panel *panel)
+static void panel_delete(const bContext *C, ARegion *region, ListBase *panels, Panel *panel)
 {
   /* Recursively delete children. */
   LISTBASE_FOREACH_MUTABLE (Panel *, child, &panel->children) {
-    panel_delete(region, &panel->children, child);
+    panel_delete(C, region, &panel->children, child);
   }
   BLI_freelistN(&panel->children);
 
-  panel_free_block(region, panel);
+  panel_free_block(C, region, panel);
 
   BLI_remlink(panels, panel);
   if (panel->activedata) {
@@ -386,7 +386,7 @@ void UI_panels_free_instanced(bContext *C, ARegion *region)
       }
 
       /* Free the panel and its sub-panels. */
-      panel_delete(region, &region->panels, panel);
+      panel_delete(C, region, &region->panels, panel);
     }
   }
 }

Re the handlers - just with a few mouse movements I don't see this effect, what do you do to trigger it? But also, this doesn't concern me too much, the logic there only checks if the mouse hovers some button or handles button activation events. Nothing expensive and nothing that would break things. Of course still nice to avoid.

The active button should be properly exited when the block gets removed. The panel removal code actually does the block removal just fine, it just needs the context to properly exit the button. I.e. I'd propose the following fix: ```lines=13 diff --git a/source/blender/editors/interface/interface_panel.c b/source/blender/editors/interface/interface_panel.c index dd3074d6258..799a3b7fd5e 100644 --- a/source/blender/editors/interface/interface_panel.c +++ b/source/blender/editors/interface/interface_panel.c @@ -321,7 +321,7 @@ void UI_list_panel_unique_str(Panel *panel, char *r_name) * Remove the #uiBlock corresponding to a panel. The lookup is needed because panels don't store * a reference to their corresponding #uiBlock. */ -static void panel_free_block(ARegion *region, Panel *panel) +static void panel_free_block(const bContext *C, ARegion *region, Panel *panel) { BLI_assert(panel->type); @@ -334,7 +334,7 @@ static void panel_free_block(ARegion *region, Panel *panel) LISTBASE_FOREACH (uiBlock *, block, &region->uiblocks) { if (STREQ(block->name, block_name)) { BLI_remlink(&region->uiblocks, block); - UI_block_free(NULL, block); + UI_block_free(C, block); break; /* Only delete one block for this panel. */ } } @@ -347,15 +347,15 @@ static void panel_free_block(ARegion *region, Panel *panel) * \note The only panels that should need to be deleted at runtime are panels with the * #PNL_INSTANCED flag set. */ -static void panel_delete(ARegion *region, ListBase *panels, Panel *panel) +static void panel_delete(const bContext *C, ARegion *region, ListBase *panels, Panel *panel) { /* Recursively delete children. */ LISTBASE_FOREACH_MUTABLE (Panel *, child, &panel->children) { - panel_delete(region, &panel->children, child); + panel_delete(C, region, &panel->children, child); } BLI_freelistN(&panel->children); - panel_free_block(region, panel); + panel_free_block(C, region, panel); BLI_remlink(panels, panel); if (panel->activedata) { @@ -386,7 +386,7 @@ void UI_panels_free_instanced(bContext *C, ARegion *region) } /* Free the panel and its sub-panels. */ - panel_delete(region, &region->panels, panel); + panel_delete(C, region, &region->panels, panel); } } } ``` Re the handlers - just with a few mouse movements I don't see this effect, what do you do to trigger it? But also, this doesn't concern me too much, the logic there only checks if the mouse hovers some button or handles button activation events. Nothing expensive and nothing that would break things. Of course still nice to avoid.

Hans Goudey commented

2020-08-05 23:32:27 +02:00

Oh, I forgot about that panel deletion! I'll commit that change you suggested, that's definitely the right way to go.

With P1571 I can get handlers for other areas to reset the cursor like this:
Screencast from 08-05-2020 05:25:38 PM.webm
Maybe I'll look into making a separate patch that can stop other area's handlers from running. Agreed though, not the highest priority.

Oh, I forgot about that panel deletion! I'll commit that change you suggested, that's definitely the right way to go. With [P1571](https://archive.blender.org/developer/P1571.txt) I can get handlers for other areas to reset the cursor like this: [Screencast from 08-05-2020 05:25:38 PM.webm](https://archive.blender.org/developer/F8750028/Screencast_from_08-05-2020_05_25_38_PM.webm) Maybe I'll look into making a separate patch that can stop other area's handlers from running. Agreed though, not the highest priority.

blender-admin commented

2020-08-05 23:36:16 +02:00

This issue was referenced by c5b6b3d82f

This issue was referenced by c5b6b3d82f56b6da1fce19b961fa444745dbc269

Hans Goudey commented

2020-08-05 23:38:19 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Hans Goudey closed this issue

2020-08-05 23:38:19 +02:00

Hans Goudey self-assigned this 2020-08-05 23:38:19 +02:00

Thomas Dinges added this to the 2.90 milestone 2023-02-08 16:26:16 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cursor icon stuck in scroll mode #78698