Camera freezes when enabling/disabling dragging behavior on a mesh

Hi there,
i don’t know if it’s a bug or my mistake.
I’m facing a strange problem when playing with dragging behavior.
This is my PG:

Here it is how to reproduce the issue:

  • click on a cube with right mouse button
  • the mesh is highlighted and the dragging behavior is anabled
  • you can drag the cube around
  • if you right click on another cube, the current selected cube is deselected and the dragging behavoir is disabled
  • the problem occours when you right click on the same cube: the camera freezes and it is not possible to move or rotate. If you right click on the same cube it returns to work

It is a bug or where do i mistake?
Thank you in advance.

An easier repro is simply to right click on a box to select it then right click it again to unselect: we can’t rotate/zoom the scene with the mouse anymore.

The culprit is line 180: sel.getBehaviorByName('PointerDrag').enabled = false;

When commentting it the camera is not freezed anymore. However, I don’t know why disabling the dragging behaviour of a mesh would disable the behaviour of the camera…

Adding @PolygonalSun as he is our master of input management!

1 Like

The strange thing is that if i use that line of code from the console (without passing throught the Pointer event), it works! It’s very odd.

I’ve made sel global so it is reacheable from the console:
I update the first post too.

Lemme take a look and see what’s going on

1 Like

Hi @PolygonalSun,
any news about this issue? Did you figure out what’s going on?
Thank you :wink:

I haven’t been able to find the root cause just yet but my plan is to track it down today. I’ll let you know what I find asap

1 Like

I did couple of things

  • Commented Line 49 - you are attaching canvas control twice
    // camera.attachControl(canvas, true);

  • Commented Line 179 - it was hard to see whether you actually need it
    // sel.getBehaviorByName('PointerDrag').enabled = false;

Not sure if it actually breaks anything. Perhaps someone else can take a second look at this.

Check this out @Mercurio

I would strongly encourage to make code examples as small as possible to make it bit more readable, thus easier to go through, meaning “get help faster” :wink:

Ah! Looked up behaviours in docs and did some console logs. Commenting L179 prevents freeze but doesn’t really disable dragging behaviour on element.

bummer!!! :thinking: I did break it, obviously!

Removing and re-attaching behaviour seems to fix the “freeze” problem.

Yeah, it does look like a bug in the end. :slight_smile:


Ok… Another 2cents… :slight_smile:

I have looked at behaviour source code and it looks like during dragging camera controls are detached. Screen doesn’t really freeze, controls just stay detached.

I gave it a go in the playground#51, rolled back to setting enabled to false and added drag release (L179, 180)

  sel.getBehaviorByName('PointerDrag').enabled = false;

It fixes the problem with the playground code. @PolygonalSun @Evgeni_Popov quick fix might be turning enabled to a setter checking if camera controls were detached and if yes re-attaching it.

Hope it helps.


@MarkBevels great catch! That correlates with what I’ve been seeing. The way that the behavior works is that, if the detachCameraControls flag is true, the controls will be detached from the camera when the startDrag method is called. When the pointer button is release, the releaseDrag method is called and the camera controls should be restored. When a PointerDragBehavior is disabled, it will automatically return before ever running either startDrag or releaseDrag so your order of operations looks something like:

<Selecting a mesh>
* Right click on Mesh
* Check for Down behavior but do nothing because Behavior is disabled
* Enable Behavior
* Run Drag Check for Up (releaseDrag)

<Deselecting a mesh>
* Right click on Mesh
* Run Drag Check for Down (startDrag; detaches controls)
* Disable Behavior
* Check for Up behavior but do nothing because Behavior is disabled (never runs releaseDrag)

This pretty much means that the reason why it doesn’t work because the code disables the behavior before the behavior reattaches the controls.

I think that it’d be good to add a contingency to the enabled check in PointerDragBehavior to make sure that the controls are reattached if the behavior gets disabled before releaseDrag is run

1 Like

I’ll need to run a couple of tests just to verify that I don’t break anything but this should be a simple fix.

Fix is in PR: Added check for PointerDragBehavior to reenable camera controls, if not reenabled before behavior is disabled by PolygonalSun · Pull Request #9841 · BabylonJS/Babylon.js (


Thank you guys, you are very effective and so quick to solve problems.
Thank you so much for your time.

Yes i know, and sorry for that. This is a PG that i use for many test related to the same application so it’s quite good for me to have the code all in the same place. Anyway for future issues i’ll try to make dedicated PG. Thank you!

HI @PolygonalSun,
i don’t know how you manage the fixes. I mean, when you commit the fix on github how can we apply to our project? We must wait for the last major release or we can download the fix from github? The fix is .min version?
Thank you, and sorry for the question…but i’m a newbie :slight_smile:

No worries, we’ve all gotta start somewhere. As far as getting the new chagnes, any fixes that are merged in should be available the next day in the nightly builds which I believe that you can find at


Thank you, now it’s clear. And what about production site? Can I use a preview package for production or have to wait for new release? If a preview has some important fixes, can we use it or it is an unstable version?

ok, i see that preview version is 5.0.0 alpha. So i can’t use it in production.
So, the question is: for all the 4.2.0 bug fixes we have to wait for 5.0.0 release, or is it expected to release a 4.2.1?
Thank’s :wink: