Disable selection in viewport problem - papercut, design issue or a bug?


  • Objects with “disable selection in viewport” cannot be selected in any other way.

I think you should be able to select these objects from the Outliner or with Python.

So if I use the “disable selection in viewport” in the Outliner on a object, it can’t be selected in any other way (with python, with select hierarchy, selecta all, in the Outliner).

Let’s say you have a long hierarchy of objects and for many of them you disabled the selection so don’t select them by mistake in the viewport.
Now if you try to move this hierarchy in a different collections you won’t be able to do it with “select hierarchy”. You can make a selection in the Outliner, but they are not actually selected so you can’t do other operations on these objects like “Apply Objects Transform” for example.

Blender Manual - Outliner section says:

Selectability (mouse cursor icon)
This is useful for if you have placed something in the scene and do not want to accidentally select it when working on something else.

Exactly, but I think you should be able to select these objects from the Outliner or with Python.
I’m coming from Maya (so I’m biased, this is how it works there.) What do you think?


I think you should be able to select these objects from the Outliner or with Python.
+1 We completely agree on this.

There are several points in all this:

  • The tooltip by itself is quite ambigous since it says 2 things at the same time:
    We assume the line to keep is “Disable selection in viewport” since it is the most specialized and also because it is related to the “Selectable” checkbox of the “Visibility” rollout and this one is cleary related to the viewport (cf https://docs.blender.org/manual/en/latest/scene_layout/object/properties/visibility.html)
    So there is a thing to be fixed here.

  • Since it is admitted that the scope of the selection is in the viewport then there is a UI inconsistency here (and here I add @billrey in the loop): either the tooltip is the reference and the design has to be modified to match it (ie selection is prevented in the viewport only), OR it is an assumed design will that the selection is locked everywhere and then the tooltip (and “Visibility->Selectable” checkbox feature tooltip too) is modified to reflect this.

  • From a dev point of view: This feature should be UI only and should not affect the way we interact with objects in Python. Otherwise it requires a systematic test of the “selectability” of objects everytime we use the selection functions and is considerably weight the code. We are in favor of a fix here.

  • From the user point of view: Preventing a mis-selection in the viewport is one thing - and that’s really helpfull. Completely preventing the selection of an object is another. It appears to be quite restrictive at the moment since the Outliner is a safer way of interacting with the content of the scene. There are some side effects (or ambigous behaviors) at the moment such as the Select Hierarchy, which may not select everything and the user may not now it when the object branch is collapsed and the hierarchy is long. Or the fact that since the lock object’s properties are still available we can change the value of the transformation anyway…
    Also if we wanted to provide a strong visual feedback for the user in the Outliner maybe we should gray (like disabled) its name in the tree view. And also put some sort of visual feedback up to the parent name so that as a user we know, when the hierarchy is collapsed, that at least one of the children is selection locked…
    At the contrary it looks like those points would not appear as issues if the object would be selected in the viewport when selected in the Outliner…

Moreover making objects still selectable from the Outliner would make the feature work as Maya or 3dsMax, so more predictable for new users. I completely acknowlege this may not be a valuable argument here since Blender has its own philosophy and writes its own path, nevertheless those applications provide good references (and appreciated ones on that topic) so evaluate if that’s the behavior we want for Blender at the end.

At last I would like to underline an inconsistency between the underlined issue here and the behavior of the filter “View Object Type” (misleading tooltip here since the dialog box is about Selection as much as View). Indeed when a type is set as not selectable in that dialog box, such as Mesh for example, mesh objects are not selectable directly in the viewport but are still selectable in the viewport from the Outliner! Exaclty the behavior we would like to have with the Selectable state of the Outliner.


So maybe at the end there are a few behavior fixes to do here…What do you think?
Could be done for 1.82?

Thank you


Thank you @Werwack for explaining this issue in detail! I completely agree with what you said.

In the current state the “disable selection” tend to cause problems for my workflow and I need to use scripts to deal with hierarchies that contain objects with “disable selection”.

That would be a great change, I fully agree with everything that has been brought up here. All the recent refinements for the outliner made it much better, but synced selections are one thing and syncing/adopting viewport restrictions in the outliner is another thing. Viewport restrictions should not be applied to the outliner itself.

That’s eg. also true for selecting other objects while you are in edit mode.

Changing selections in the outliner will most likely be intentional if you were in edit mode before, so it also needs no protection like the viewport, momentarily it’s quite cumbersome to change the edited object, especially since interactionmode shortcuts are not active if you hover over the outliner.

This is not meant as an additional wish being put into this proposal, its more that it demonstrates that these restrictions should generally be less for the outliner.

1 Like

Would it be possible to have an update or answer from the design team here please? That’s an important point in production.
Thank you


I’m pushing that topic to the front again to see if it would be possible to address it at some point.