https://www.babylonjs-playground.com/#7PZ7QH#10
Geez, I’m getting a lot of impostor = null from firefox, too, now… line 157. Always on 2nd+ running. First runs, no errors/warnings. I need to get that setInterval and onDispose thing out of there. 4 gui buttons instead… weebleSphere control buttons… left, right, forward, backward. That interval-based random thing is making the physics engines vomit. NOTHING likes setInterval… me thinks. 
Update: Version with setInterval on redSphere removed… works better for me.
Anyway, look at lines 170-182… to understand a bit more about registering and un-registering functions… which run when physics collide happens. Here, we first register a function named barney… in line 175. Drag greenbox against red sphere while watching console. Lots of collide indicators. After 10 seconds, I unregister barney… so no more greenbox->redsphere console-report-on-collision… after 10 seconds.
I don’t think we have OnPhysicsCollideEND or similar, at least not at plugin layer. Deep in physics engine native lands… maybe it’s available. Arte, if you are (seriously) working-on a physics-based “snap” (possibly for your cabinet-making project or similar projects), then I’ll try to research how physics engines de-overlap and clear-collisions… on impostors. Each does it somewhat differently, I suspect.
I also suspect an impostor can be colliding with multiple other impostors at the same time. There may be a collisionsManager on a physics engine world-class object. If you are going deep-diving, I’ll do my best to help… but… those physics formulas (solvers) are rather “tight’n’terse”… easily surpassing Wingnut’s math intelligence levels. At a certain point in the deep research, it is probably best to move me from a tech role… to a food’n’beer-fetching role.
Extra: @Cedric taught me that “static objects” and “dynamic objects” are two different classes of physics bodies, and not just a difference of state or a difference of a property. i think this is why sphere->ground collisions are not registered as onCollides (as best I can tell). it is because ground has mass=0… making it static… I suspect. This means that setMass() is our switching method… to switch a physicsBody object from being… for example, isSleeping dynamic object, to a static, and reverse.
Here’s where the defecation hits the fan. There is a plugin-layer setMass(), AND a native-level way to set the physicsBody mass, ALSO. I believe, the plugin-level setMass()… also performs a forceUpdate (replaces the impostor with a new one)… which… will disconnect any joints that you once had attached to that shape. And naturally, there are ramifications to “going static” or “going dynamic”… especially if that impostor is currently doing joint-caused or force-caused physics movements. Also consider comparing plugin-level mass-setting methods (on the physicsImpostor)… with native-level ways (on the physicsImpostor.physicsBody). They may have differing side-effects.
Also, when calling native-level methods, you MIGHT have to use PE-types for your values. In other words, new CANNON.Vec3(x,y,z) instead of new BABYLON.Vector3(x,y,z). SOMETIMES the BJS datatypes cross-into/out-of native lands… nicely… but it is best to feed native functions… with native foods. One particular point of interest… a Cannon Quaternion-type has a .toEuler(needsStuffHere)… and a Babylon Quaternion has a .toEulerAngles(nothingNeededHere). BOTH may be used fairly extensively (for console.logs)… when studying physics engines.
BUT, there is a lightly-tested theory/rumor… that mesh.rotationQuaternion is always exactly mirroring mesh.physicsImpostor.physicsBody.quaternion. In theory, they HAVE TO be mirroring, as that is the “rotational connection system” between mesh and physicsBody. Position is the other primary mesh-to-PB connection. The MOST un-tested part… is setting mesh.rotationQuaternion WHILE an impostor is already installed. Does the value get transfered all the way “down” -to PB.quaternion? Does the value get changed (casted?) from a BJS quat… into a Cannon quat… on the way? hmm.
@Arte , could you please do some Google Chrome tests on the PG version with removed setInterval/onDispose crap? Please report if you are able to call a setLinearVelocity or setAngularVelocity (and forceUpdate() and setMass(), too)… maybe after a short setTimeout delay. I think it will work without errors. I think setInterval is (was) causing our hassles… mostly because I don’t think Wingnut knows how to use it “properly”. I think the onDispose/clearInterval of fred… is somehow killing the physics engine for not-first-time-RUNs, when used in the playground. (what a mouthful of hypothesis, eh?)
And here you are with “Bidibulle”, “Weebl and Bob” 
