Double clicking on text edit controls doesn't select the full word #84830

New Issue

Daniel Santana · 2021-01-18T17:43:43+01:00

Daniel Santana commented

2021-01-18 17:43:43 +01:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce RTX 2080 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 461.09

Blender Version
Broken: version: 2.93.0 Alpha, branch: master, commit date: 2021-01-18 13:07, hash: 3584f1d224
2.91 release
Worked: unknown

Short description of error
Double clicking on text edit controls doesn't select the full word.

Exact steps for others to reproduce the error
Just open the default blender and try to select the cube name on the properties, please place the mouse cursor in the middle of the Cube word, and double click.
e8rUuja443.mp4

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce RTX 2080 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 461.09 **Blender Version** Broken: version: 2.93.0 Alpha, branch: master, commit date: 2021-01-18 13:07, hash: `3584f1d224` 2.91 release Worked: unknown **Short description of error** Double clicking on text edit controls doesn't select the full word. **Exact steps for others to reproduce the error** Just open the default blender and try to select the cube name on the properties, please place the mouse cursor in the middle of the Cube word, and double click. [e8rUuja443.mp4](https://archive.blender.org/developer/F9585638/e8rUuja443.mp4)

Daniel Santana commented

2021-01-18 17:43:43 +01:00

Added subscriber: @dgsantana

blender-admin commented

2021-01-18 17:43:43 +01:00

#102207 was marked as duplicate of this issue

Falk David commented

2021-01-18 19:30:53 +01:00

Added subscriber: @filedescriptor

Falk David commented

2021-01-18 19:30:53 +01:00

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

Falk David commented

2021-01-18 19:30:53 +01:00

I found a way to reproduce this: If I use my mouse, double-clicking will always select the whole word but when I use my tablet pen, it does not.

Falk David commented

2021-01-18 19:33:51 +01:00

First with the mouse, then with tablet pen Peek 2021-01-18 19-33.webm
OS: Linux 5.8.0-7630-generic

First with the mouse, then with tablet pen [Peek 2021-01-18 19-33.webm](https://archive.blender.org/developer/F9585823/Peek_2021-01-18_19-33.webm) OS: Linux 5.8.0-7630-generic

Daniel Santana commented

2021-01-18 19:53:55 +01:00

I do have a wacom tablet, but I use a regular mouse, most the time, and the video was done with the mouse.

Daniel Santana commented

2021-01-18 19:55:28 +01:00

I noticed this first on the file browser, where I normally "pick"/double click to replace words.

Nicholas Rishel commented

2021-01-18 23:10:23 +01:00

Added subscriber: @PrototypeNM1

Nicholas Rishel commented

2021-01-18 23:10:23 +01:00

Verified this issue (for tablets) predates Blender 2.92, thus is unrelated to recent Wintab changes.

Campbell Barton commented

2021-01-19 04:50:57 +01:00

Added subscriber: @ideasman42

Campbell Barton commented

2021-01-19 04:50:57 +01:00

Suspect this issue is small mouse-move events cause the word selection to be lost.

We could ignore dragging after a double-click event.

Suspect this issue is small mouse-move events cause the word selection to be lost. We could ignore dragging after a double-click event.

Hans Goudey commented

2021-01-19 05:39:48 +01:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2021-01-19 05:39:48 +01:00

In other applications, double clicking enters "word select mode", where dragging will select words instead of letters. Might be worth supporting that, since it's much more intuitive than ignoring drags.

Campbell Barton commented

2021-01-19 10:02:56 +01:00

Supporting select-word drag would be nice but more of a TODO, this could be solved separately if a small patch resolved this report.

Harley Acheson commented

2021-01-23 00:04:27 +01:00

Added subscriber: @Harley

Harley Acheson commented

2021-01-23 00:04:27 +01:00

Only mentioning the following because I don't see it noted here.

I agree that double-clicking on a word should select the entire word, but currently individual words can be selected if you do so at the end of the word. Again, mostly mentioning this in case it is a clue to the behavior and how it can be fixed or improved.

Only mentioning the following because I don't see it noted here. I agree that double-clicking on a word should select the entire word, but currently individual words *can* be selected if you do so at the end of the word. Again, mostly mentioning this in case it is a clue to the behavior and how it can be fixed or improved. ![SelectWords.gif](https://archive.blender.org/developer/F9592990/SelectWords.gif)

Jesse Yurkovich commented

2021-01-23 00:49:43 +01:00

Added subscriber: @deadpin

Jesse Yurkovich commented

2021-01-23 00:49:43 +01:00

A git bisect shows that d5c59913de is the first bad commit.

A git bisect shows that d5c59913de is the first bad commit.

Nicholas Rishel commented

2021-01-23 04:35:56 +01:00

In #84830#1099028, @deadpin wrote:
A git bisect shows that d5c59913de is the first bad commit.

I can recreate the issue in 2.91 release, predating this commit. More likely the issue is more reproducible due to higher frequency input, maybe relates to how the operator handles coalesced mouse input?

Notably, the whole word is selected followed by a snap back to the cursor.

Additionally with mouse input, double click and hold followed by mouse moves results in inconsistent behavior as you move back and forth.

> In #84830#1099028, @deadpin wrote: > A git bisect shows that d5c59913de is the first bad commit. I can recreate the issue in 2.91 release, predating this commit. More likely the issue is more reproducible due to higher frequency input, maybe relates to how the operator handles coalesced mouse input? Notably, the whole word is selected followed by a snap back to the cursor. Additionally with mouse input, double click and hold followed by mouse moves results in inconsistent behavior as you move back and forth.

Julian Eisel commented

2021-01-25 15:10:20 +01:00

Added subscriber: @JulianEisel

Julian Eisel commented

2021-01-25 15:10:20 +01:00

The mentioned commit may indeed have made this issue more noticeable, but only on Windows (since it only affects Windows code).

To recap:

@dgsantana reports this issue for mouse input on Windows.
@filedescriptor reports it for tablet input only on Linux (checked in the chat).
So my first suspicion is that the double click check for some reason fails for high frequency input (INBETWEEN_MOUSEMOVE?), which is typical for tablets and apparently now for mice on Windows too (? The commit is not clear on that to me).

I can't recreate this with mouse or touchpad here (macOS). Don't have access to a tablet to test. So I didn't actually debug this.

The mentioned commit may indeed have made this issue more noticeable, but only on Windows (since it only affects Windows code). To recap: * @dgsantana reports this issue for mouse input on Windows. * @filedescriptor reports it for tablet input only on Linux (checked in the chat). So my first suspicion is that the double click check for some reason fails for high frequency input (`INBETWEEN_MOUSEMOVE`?), which is typical for tablets and apparently now for mice on Windows too (? The commit is not clear on that to me). I can't recreate this with mouse or touchpad here (macOS). Don't have access to a tablet to test. So I didn't actually debug this.

Nicholas Rishel commented

2021-01-25 23:45:31 +01:00

More context: I can reliably recreate the issue on Blender 2.82 by double clicking while slightly moving the mouse.

Nicholas Rishel commented

2021-01-26 00:28:20 +01:00

I think I know what's happening now. Either the way the window manager handles generating double click events or the select full word operator's implementation are reliant on the assumption of no mouse move events are generated between the two clicks or that no mouse events are generated during a single click (press and release). What changed in the high frequency mouse input commit was that mouse moves are generated in more cases, sometimes redundantly when no mouse move has occurred.

I can modify how mouse events are generated in Ghost to check that the mouse actually moved before creating an event, after testing this did fix the issue. This however won't address tablet input which by it's nature tends to move during a double click.

I'm not sure how the select full word operator is implemented, afaik it could be re-implementing double click instead of subscribing to the Window Manager generated events. Depending on that would impact how best to proceed.

I think I know what's happening now. Either the way the window manager handles generating double click events or the select full word operator's implementation are reliant on the assumption of no mouse move events are generated between the two clicks or that no mouse events are generated during a single click (press and release). What changed in the high frequency mouse input commit was that mouse moves are generated in more cases, sometimes redundantly when no mouse move has occurred. I can modify how mouse events are generated in Ghost to check that the mouse actually moved before creating an event, after testing this did fix the issue. This however won't address tablet input which by it's nature tends to move during a double click. I'm not sure how the select full word operator is implemented, afaik it could be re-implementing double click instead of subscribing to the Window Manager generated events. Depending on that would impact how best to proceed.

Campbell Barton commented

2021-01-26 23:05:54 +01:00

In #84830#1100228, @JulianEisel wrote:
I can't recreate this with mouse or touchpad here (macOS). Don't have access to a tablet to test. So I didn't actually debug this.

I can redo this on a regular linux/X11 setup with a mouse (although not every time).

A straightforward fix for this would be to apply some threshold for mouse-movement after a double-click.

> In #84830#1100228, @JulianEisel wrote: > I can't recreate this with mouse or touchpad here (macOS). Don't have access to a tablet to test. So I didn't actually debug this. I can redo this on a regular linux/X11 setup with a mouse (although not every time). A straightforward fix for this would be to apply some threshold for mouse-movement after a double-click.

Vincent Blankfield commented

2021-01-27 18:47:45 +01:00

Added subscriber: @VincentBlankfield

Vincent Blankfield commented

2021-01-27 18:47:46 +01:00

This is caused by MOUSEMOVE events happening before KM_RELEASE. On Windows I always get the events in this order: KM_DBL_CLICK, MOUSEMOVE, KM_RELEASE. MOUSEMOVE happens even if the mouse didn't move. Clicking a touchpad button without touching the touchpad still generates it, for example.

Problem
In ui_do_but_textedit this part will select a word and leave the button in BUTTON_STATE_TEXT_SELECTING state:

LINES=10
      /* only select a word in button if there was no selection before */
      if (event->val == KM_DBL_CLICK && had_selection == false) {
        ui_textedit_move(but, data, STRCUR_DIR_PREV, false, STRCUR_JUMP_DELIM);
        ui_textedit_move(but, data, STRCUR_DIR_NEXT, true, STRCUR_JUMP_DELIM);
        retval = WM_UI_HANDLER_BREAK;
        changed = true;
      }
      else if (inbox) {
        /* if we allow activation on key press,
         * it gives problems launching operators T35713. */
        if (event->val == KM_RELEASE) {
          button_activate_state(C, but, BUTTON_STATE_EXIT);
          retval = WM_UI_HANDLER_BREAK;
        }
      }

In ui_do_but_textedit_select this part will deselect a part of the word after the cursor position on MOUSEMOVE, before the BUTTON_STATE_TEXT_SELECTING state is exited on KM_RELEASE event:

LINES=10
  switch (event->type) {
    case MOUSEMOVE: {
      int mx = event->x;
      int my = event->y;
      ui_window_to_block(data->region, block, &mx, &my);

      ui_textedit_set_cursor_select(but, data, event->x);
      retval = WM_UI_HANDLER_BREAK;
      break;
    }
    case LEFTMOUSE:
      if (event->val == KM_RELEASE) {
        button_activate_state(C, but, BUTTON_STATE_TEXT_EDITING);
      }
      retval = WM_UI_HANDLER_BREAK;
      break;
  }

Possible solutions

Preferred quick fix. Exit the selecting state right away, when a word has been selected. We will lose the ability to drag the selection after coubleclick select (not sure it's useful as it is anyway):

LINES=10
diff --git a/source/blender/editors/interface/interface_handlers.c b/source/blender/editors/interface/interface_handlers.c
index f9634b8f731..2bee9db7947 100644
--- a/source/blender/editors/interface/interface_handlers.c
+++ b/source/blender/editors/interface/interface_handlers.c
@@ -3609,6 +3609,8 @@ static void ui_do_but_textedit(
         ui_textedit_move(but, data, STRCUR_DIR_NEXT, true, STRCUR_JUMP_DELIM);
         retval = WM_UI_HANDLER_BREAK;
         changed = true;
+        /* Exit selecting state right away to prevent deselecting by MOUSEMOVE before KM_RELEASE (T84830) */
+        button_activate_state(C, but, BUTTON_STATE_TEXT_EDITING);
       }
       else if (inbox) {
         /* if we allow activation on key press,

Allow some mouse movement threshold before dragging the selection. This one feels a bit hacky, may have issues on smaller fonts. Also it is unnecessary complicated as it will require accumulating the mouse movement. Simply checking consecutive movement events will give distance of 1-2 pixels between them.
Somehow make sure there's no MOUSEMOVEs before the KM_RELEASE. This is unreliable, because a real small movement may happen.
Preferred (not-so-quick) solution. Implement a word drag select. Not a big change, but requires passing a bool between ui_do_but_textedit_select and ui_do_but_textedit. May be something like this:

LINES=10
diff --git a/source/blender/editors/interface/interface_handlers.c b/source/blender/editors/interface/interface_handlers.c
index f9634b8f731..a8207af70d6 100644
--- a/source/blender/editors/interface/interface_handlers.c
+++ b/source/blender/editors/interface/interface_handlers.c
@@ -416,6 +416,9 @@ typedef struct uiHandleButtonData {
   /* post activate */
   uiButtonActivateType posttype;
   uiBut *postbut;
+
+  /* Double click and drag */
+  bool is_word_drag_select;
 } uiHandleButtonData;

 typedef struct uiAfterFunc {
@@ -3520,6 +3523,9 @@ static void ui_do_but_textedit(
   const bool is_ime_composing = false;
 #endif

+  // Is there a better place to init this?
+  data->is_word_drag_select = false;
+
   switch (event->type) {
     case MOUSEMOVE:
     case MOUSEPAN:
@@ -3609,6 +3615,9 @@ static void ui_do_but_textedit(
         ui_textedit_move(but, data, STRCUR_DIR_NEXT, true, STRCUR_JUMP_DELIM);
         retval = WM_UI_HANDLER_BREAK;
         changed = true;
+        data->is_word_drag_select = true;
       }
       else if (inbox) {
         /* if we allow activation on key press,
@@ -3861,11 +3870,18 @@ static void ui_do_but_textedit_select(
       ui_window_to_block(data->region, block, &mx, &my);

       ui_textedit_set_cursor_select(but, data, event->x);
+
+      if (data->is_word_drag_select) {
+        eStrCursorJumpDirection direction = (but->pos > but->selsta) ? STRCUR_DIR_NEXT : STRCUR_DIR_PREV;
+        ui_textedit_move(but, data, direction, true, STRCUR_JUMP_DELIM);
+      }
+
       retval = WM_UI_HANDLER_BREAK;
       break;
     }
     case LEFTMOUSE:
       if (event->val == KM_RELEASE) {
+        data->is_word_drag_select = false;
         button_activate_state(C, but, BUTTON_STATE_TEXT_EDITING);
       }
       retval = WM_UI_HANDLER_BREAK;

This is caused by `MOUSEMOVE` events happening before `KM_RELEASE`. On Windows I always get the events in this order: `KM_DBL_CLICK`, `MOUSEMOVE`, `KM_RELEASE`. `MOUSEMOVE` happens even if the mouse didn't move. Clicking a touchpad button without touching the touchpad still generates it, for example. **Problem** In `ui_do_but_textedit` this part will select a word and leave the button in `BUTTON_STATE_TEXT_SELECTING` state: ``` LINES=10 /* only select a word in button if there was no selection before */ if (event->val == KM_DBL_CLICK && had_selection == false) { ui_textedit_move(but, data, STRCUR_DIR_PREV, false, STRCUR_JUMP_DELIM); ui_textedit_move(but, data, STRCUR_DIR_NEXT, true, STRCUR_JUMP_DELIM); retval = WM_UI_HANDLER_BREAK; changed = true; } else if (inbox) { /* if we allow activation on key press, * it gives problems launching operators T35713. */ if (event->val == KM_RELEASE) { button_activate_state(C, but, BUTTON_STATE_EXIT); retval = WM_UI_HANDLER_BREAK; } } ``` In `ui_do_but_textedit_select` this part will deselect a part of the word after the cursor position on `MOUSEMOVE`, before the `BUTTON_STATE_TEXT_SELECTING` state is exited on `KM_RELEASE` event: ``` LINES=10 switch (event->type) { case MOUSEMOVE: { int mx = event->x; int my = event->y; ui_window_to_block(data->region, block, &mx, &my); ui_textedit_set_cursor_select(but, data, event->x); retval = WM_UI_HANDLER_BREAK; break; } case LEFTMOUSE: if (event->val == KM_RELEASE) { button_activate_state(C, but, BUTTON_STATE_TEXT_EDITING); } retval = WM_UI_HANDLER_BREAK; break; } ``` **Possible solutions** 1. Preferred quick fix. Exit the selecting state right away, when a word has been selected. We will lose the ability to drag the selection after coubleclick select (not sure it's useful as it is anyway): ``` LINES=10 diff --git a/source/blender/editors/interface/interface_handlers.c b/source/blender/editors/interface/interface_handlers.c index f9634b8f731..2bee9db7947 100644 --- a/source/blender/editors/interface/interface_handlers.c +++ b/source/blender/editors/interface/interface_handlers.c @@ -3609,6 +3609,8 @@ static void ui_do_but_textedit( ui_textedit_move(but, data, STRCUR_DIR_NEXT, true, STRCUR_JUMP_DELIM); retval = WM_UI_HANDLER_BREAK; changed = true; + /* Exit selecting state right away to prevent deselecting by MOUSEMOVE before KM_RELEASE (T84830) */ + button_activate_state(C, but, BUTTON_STATE_TEXT_EDITING); } else if (inbox) { /* if we allow activation on key press, ``` 2. Allow some mouse movement threshold before dragging the selection. This one feels a bit hacky, may have issues on smaller fonts. Also it is unnecessary complicated as it will require accumulating the mouse movement. Simply checking consecutive movement events will give distance of 1-2 pixels between them. 3. Somehow make sure there's no `MOUSEMOVE`s before the `KM_RELEASE`. This is unreliable, because a real small movement may happen. 4. Preferred (not-so-quick) solution. Implement a word drag select. Not a big change, but requires passing a bool between `ui_do_but_textedit_select` and `ui_do_but_textedit`. May be something like this: ``` LINES=10 diff --git a/source/blender/editors/interface/interface_handlers.c b/source/blender/editors/interface/interface_handlers.c index f9634b8f731..a8207af70d6 100644 --- a/source/blender/editors/interface/interface_handlers.c +++ b/source/blender/editors/interface/interface_handlers.c @@ -416,6 +416,9 @@ typedef struct uiHandleButtonData { /* post activate */ uiButtonActivateType posttype; uiBut *postbut; + + /* Double click and drag */ + bool is_word_drag_select; } uiHandleButtonData; typedef struct uiAfterFunc { @@ -3520,6 +3523,9 @@ static void ui_do_but_textedit( const bool is_ime_composing = false; #endif + // Is there a better place to init this? + data->is_word_drag_select = false; + switch (event->type) { case MOUSEMOVE: case MOUSEPAN: @@ -3609,6 +3615,9 @@ static void ui_do_but_textedit( ui_textedit_move(but, data, STRCUR_DIR_NEXT, true, STRCUR_JUMP_DELIM); retval = WM_UI_HANDLER_BREAK; changed = true; + data->is_word_drag_select = true; } else if (inbox) { /* if we allow activation on key press, @@ -3861,11 +3870,18 @@ static void ui_do_but_textedit_select( ui_window_to_block(data->region, block, &mx, &my); ui_textedit_set_cursor_select(but, data, event->x); + + if (data->is_word_drag_select) { + eStrCursorJumpDirection direction = (but->pos > but->selsta) ? STRCUR_DIR_NEXT : STRCUR_DIR_PREV; + ui_textedit_move(but, data, direction, true, STRCUR_JUMP_DELIM); + } + retval = WM_UI_HANDLER_BREAK; break; } case LEFTMOUSE: if (event->val == KM_RELEASE) { + data->is_word_drag_select = false; button_activate_state(C, but, BUTTON_STATE_TEXT_EDITING); } retval = WM_UI_HANDLER_BREAK; ```

Nicholas Rishel commented

2021-01-28 01:02:27 +01:00

Without looking at the relevant operator code further than @VincentBlankfield's excellent analysis, I think you could implement word drag select (and paragraph select) by separating the drag select origin into left/right origins.

@VincentBlankfield in case you didn't want to submit a patch, I'd be interested in implementing this. There's a reasonable path to a robust fix; in the case I don't have time before 2.92 release there's a simple way to return to the prior state of things (make Ghost filter out non-moving mouse move events).

Without looking at the relevant operator code further than @VincentBlankfield's excellent analysis, I think you could implement word drag select (and paragraph select) by separating the drag select origin into left/right origins. @VincentBlankfield in case you didn't want to submit a patch, I'd be interested in implementing this. There's a reasonable path to a robust fix; in the case I don't have time before 2.92 release there's a simple way to return to the prior state of things (make Ghost filter out non-moving mouse move events).

Nicholas Rishel self-assigned this 2021-02-07 20:09:22 +01:00

Nicholas Rishel commented

2021-02-17 03:33:46 +01:00

Note, 2e81f2c01a returned Blender to the same behavior as present in 2.91.

I'm leaving the issue open for now as double click selection behavior could still be improved, but the remaining issue is no longer a regression.

Note, 2e81f2c01a returned Blender to the same behavior as present in 2.91. I'm leaving the issue open for now as double click selection behavior could still be improved, but the remaining issue is no longer a regression.

Pratik Borhade commented

2022-11-01 14:40:54 +01:00

Added subscriber: @PratikPB2123

Pratik Borhade commented

2022-11-01 14:40:54 +01:00

Report is not appearing in normal searches and issue is not particular for 2.93 so I'm removing BF Blender (2.93)

Report is not appearing in normal searches and issue is not particular for 2.93 so I'm removing `BF Blender (2.93)`

Pratik Borhade commented

2022-11-01 15:16:17 +01:00

Added subscriber: @lichtwerk

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Double clicking on text edit controls doesn't select the full word #84830