Page MenuHome

2.81 Outliner: using active object as anchor for shift-selection is fragile as it may become hidden in outliner
Closed, ArchivedPublic


Blender Version
Broken: 2.81

  1. Open a default scene (camera, cube and light).
  2. Add a torus and duplicate it. The goal is to have two objects above "Light" in outliner, and two below.
  3. In outliner, click on "Light", shift+click on the last Torus. "Light" will become active, three objects will be selected.
  4. In outliner filter settings, disable lights.
  5. Shift+click on "Camera".

If we are to indeed base our expectations on how selection behaves in other applications, then the expected result would be 4 selected objects: all geometry and a camera. But instead, everything except the camera is deselected and camera is made active. So not only is this selection approach inconsistent with the rest of Blender, it's inconsistent with itself.

Active object is what Blender's operators and editors act on. It's a very poor candidate for selection anchor.



Event Timeline

In the same vein, using extend selection:
In outliner, click on Camera, ctrl+click on Cube, ctrl+click on Cube again. In 3D viewport, the Cube is still active. In outliner, it isn't. And again, attempting to shift+select from that destroys selection and resets active object.

This is not a bug. If the light is active, then hidden from the outliner by filtering out light objects, then there is no active object in the outliner. Therefore, trying to do a range select is impossible. In your example, both Torus.001 and Torus are selected, but making a code decision to decide which to begin the range select from would be arbitrary. That is why I decided to only do range select if an active element exists.

You can always do a ctr+click to set a new active object (so insert a step 4.5 to your list where you activate the bottom Torus).

In "other applications", i.e. in a file browser, with situation as presented, a selection would've been made from the bottom torus to the top. Instead, current outliner breaks existing selection and makes a new one. It may well be working as designed, but then that means there's something wrong with the design.

EDIT: Ah, I see why there's confusion, I didn't explain myself very well. This is different fom T70843, that's why I've created this task in the first place. That issue is about making an object active with shift+click, which I understand is not always possible, and the outliner already avoids that (i.e. when modes differ).

This one is about range selection not behaving as one would expect coming from other applications. See e.g. the first comment I've added before your reply.

This seems like it belongs in the paper cut thread and not the bug tracker:

For suggestions on how to improve the UI, please use other channels: