While this is mostly compatible with the existing keymap, it overloads dragging, similar to T63994.

Issues

• You can accidentally select when dragging, pushing us to make selection act on click instead of press.
  
  Especially when Shift-Dragging you can easily unintentionally select a handle for e.g. as well as performing the border select.
  
  To me this feels like a glitch.

• You need empty space in order to border select.

Regarding border select on drag generally.

Would this be applied to other areas?

What is the rationale for applying this to some space types and not others (Object/Edit-Modes/Mask/UV-edit... etc).

In D4799#109657, @Campbell Barton (campbellbarton) wrote:

While this is mostly compatible with the existing keymap, it overloads dragging, similar to T63994.

Issues

• You can accidentally select when dragging, pushing us to make selection act on click instead of press.

I don't really follow. Dragging does select. That's the whole point. I don't see the need to changing to Click events. Why would we need that? This patch avoids that, and still works correctly.

Especially when Shift-Dragging you can easily unintentionally select a handle for e.g. as well as performing the border select.

What is the harm in that? If you hold Shift you would want to extend your selection, which this allows.

• You need empty space in order to border select.

We still have the B key. To me it's similar to clicking on empty areas to deselect, which we already do.

Regarding border select on drag generally.

Would this be applied to other areas?

What is the rationale for applying this to some space types and not others (Object/Edit-Modes/Mask/UV-edit... etc).

Well, a few things.

• By default clicking and dragging in the 3D View and UV Editor DOES perform a box select. We also do this in the Node Editor. These editors were the odd ones out, to not allow box selecting by dragging. So it adds more consistency.
• Those editors have separate select tools. But I think we should have a way to box select even when the transform tools are active. The ICK does this, but I think it should be a tool option.

The way the keymap works in this patch means you can box-select and vertex-select in one action.
The vertex maybe outside the box region you draw, making this feel like a glitch

Everywhere else in Blender you do one or the other (starting out a box select is never also activating some nearby object/vertex for eg.)

@Campbell Barton (campbellbarton) I am not able to reproduce this so-called ‘glitch’. Here it seems to work as expected. You can click to select or drag to box select, unless you are over an item, in which case dragging moves said item. To me this seems like exactly the right behavior.

When dragging to box select, I can only make it select what is actually inside the box, which is correct. I don't really follow your issue at all.

Can you give a more precise example?

Also, are you using defaults or right click selecting?

Edit: Re-tested with right-click select and there is also seems to work correctly. Obviously, box selecting is then done with RMB, but that's right-click select for ya. Node Editor works identically already.

This happens with both righ/left click select.

It's quite easy to redo.

• Hold shift.
• Press LMB near a vertex (so it selects the vertex)
• Drag the cursor (will create a box selection).

This happens even if you didn't intend to select the vertex, even if it's not inside the region of the box.

You can for example, accidentally de-select a vertex handle because the box-selection happens to be near a handle.

Attached video:

Okay. I can kindof reproduce that, but I practically have to actually be *on* that key while holding Shift to include it, in which case you would want it included in your box selection anyway. This only applies when holding Shift and beginning the box select on an item, but when you've finished your box selection with that item included, it gets properly selected anyway. So I consider that a non-issue.

I consider this patch a major improvement to the ease of use when it comes to selecting items in the animation editors, and a way to make Blender more consistent. It's the missing component after the click-in-empty-areas-to-deselect feature. Once we include box selecting by dragging in the Outliner too, we will have this behavior everywhere.

This mirrors the selecting behavior in most other apps for selecting and box selecting.

If you were previously using the B key, you can still do that, and this patch does not interfere with that workflow at all. But clicking and dragging was not used here, so I think it's the right change to make.

In D4799#109953, @William Reynish (billreynish) wrote:

Okay. I can kindof reproduce that, but I practically have to actually be *on* that key while holding Shift to include it, in which case you would want it included in your box selection anyway.

This was a bug in hi-dpi support, the selection distance wasn't scaled as it is for other modes (now fixed).

Even if the user wanted this, doing two steps causes 2x undo pushes which feels like a glitch when you run into it.

This kind of thing shouldn't be possible even by accident or rarely, we don't have this problem elsewhere so it should be avoided here too.

In D4799#109916, @Campbell Barton (campbellbarton) wrote:

The way the keymap works in this patch means you can box-select and vertex-select in one action.
The vertex maybe outside the box region you draw, making this feel like a glitch

I think this used to be a problem in pre-2.8 too; it is probably caused by the feature that selects the element closes to cursor by a certain threshold.
Not sure if it is still helpful but I believe this Stack Exchange question illustrates it in his video.

Only solution is probably once again select on mouse release instead. For what is worth I don't think it is a major issue at all, I even often use it to my advantage to set the active element at my discretion in one go.

@William Reynish (billreynish) This resolves Shift-Click conflict.

Testing further and there is a conflict when Ctrl & Ctrl-Shift are pressed since these are mapped to GRAPH_OT_select_leftright (same for action editor).

These will need to use the click event too.

@Duarte Farrajota Ramos (duarteframos), checked 2.79x and there doesn't seem to be any issues in the graph editor, the video linked looks more like a bug in 3D view box select.