First with the mouse, then with tablet pen
OS: Linux 5.8.0-7630-generic

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

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

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

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

We could ignore dragging after a double-click event.

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.

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

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.

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

In T84830#1099028, @Jesse Y (deadpin) wrote:

A git bisect shows that rBd5c59913de95b6b6952088f175a8393bef376d27 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.

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

To recap:

• @Daniel Santana (dgsantana) reports this issue for mouse input on Windows.
• @Falk David (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.

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

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.

In T84830#1100228, @Julian Eisel (Severin) 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.

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:

/* 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:

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):

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 MOUSEMOVEs 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:

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;

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

@Vincent Blankfield (vvv) 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).

Note, rB2e81f2c01abd21fdbc 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.