addons: Spacebar menu scale and rotate buttons do nothing when interacted with

[Exairnous]

Description
Applies to: #6468
Objects can't be manipulated via the scale and rotate buttons from the spacebar menu anymore. This affects both the bitECS and A-Frame loaders.

To Reproduce
Steps to reproduce the behavior:

• bitECS and A-Frame

1. Enter a Hubs room.
2. Drag and drop a GLB file that you have locally on your computer into the room (or use Place -> Upload). This file can be downloaded and used to test if you don't have any GLBs handy: Test_Cube.zip.
3. Hover over the object and press and hold the spacebar to bring up the menu (you may have to move your avatar around a bit to get it to show up).
4. Click and drag on the scale or rotate buttons while holding the spacebar.
5. See that the view moves instead of the object scaling or rotating.

• A-Frame Only

6. Spawn a media frame cube via the /cube chat command.
7. Use the media frame cube to capture the object to allow moving the object.
8. Move the object outside of the media frame (steps 6-8 work around bug #6518).
9. Hover over the object and press and hold the spacebar to bring up the menu (you may have to move your avatar around a bit to get it to show up).
10. Click and drag on the scale or rotate buttons while holding the spacebar.
11. See that the object moves instead of scaling or rotating.

Expected behavior
The object should be scaled or rotated, depending on which button is interacted with.

Hardware

• Device: Laptop
• OS: GNU/Linux
• Browser: Chromium and Firefox

Additional context
Potentially caused by #6487
Originally reported (with slight differences) against the master branch here: #6496

[HussainAther]

hi, happy to hop on board with htis one too. thank you.

[Exairnous]

@HussainAther Any help you can provide is greatly appreciated. Thank you.

I did some work previously to try to fix this, so you may find it useful as a reference: #6514

If I remember correctly, I got the buttons working, but the physics system would end up fighting them for control once first engaged (it is enabled/disabled depending on various situations).

@DougReeder also did some work trying to fix it, so you may find that useful as well. #6502

If you have any questions, don't hesitate to ask.

[HussainAther]

Thanks, once again , I'm still trying to get this work.

[HussainAther]

@HussainAther Any help you can provide is greatly appreciated. Thank you.

I did some work previously to try to fix this, so you may find it useful as a reference: #6514

If I remember correctly, I got the buttons working, but the physics system would end up fighting them for control once first engaged (it is enabled/disabled depending on various situations).

@DougReeder also did some work trying to fix it, so you may find that useful as well. #6502

If you have any questions, don't hesitate to ask.

see that PR #6502 attempted to fix the issue by modifying findAncestorWithComponents() to check for Rigidbody but not Deletable and MediaLoader. Meanwhile, PR #6514 focused on passing eid instead of bodyId to updateRigidBody and checking body-helper. However, it seems like the physics system is still interfering with rotation after an object is thrown.
Would it make sense to test if keeping Deletable and MediaLoader improves consistency in object interaction? Or do we suspect the core issue is related to state updates in updateRigidBody and physics ownership? I'm trying to figure out the best debugging approach—any thoughts on the most likely culprit?

[Exairnous]

@HussainAther

Would it make sense to test if keeping Deletable and MediaLoader improves consistency in object interaction?

I don't think so. If I recall correctly, the findAncestorWithComponents function was looking for entities that had all the specified components, so adding Deletable and MediaLoader to the passed arguments made it so it didn't find anything and always fell back to targeting the hovered entity. Also, I think this would have run into the same physics system issues as PR #6514, but I don't remember for sure.

Or do we suspect the core issue is related to state updates in updateRigidBody and physics ownership?

I believe there are two core issues here:

1. That the buttons weren't getting targeted when they were clicked (which PR #6514 should fix with its changes to src/systems/hold-system.js).
2. That the physics system isn't getting enabled/disabled properly, which is what the rest of that PR tries to fix, but it's only partially successful (so yes, I suspect this part is related to state updates in updateRigidBody and physics ownership).

Now that I look back on it, I think PR #6514 fixed the physics for the bitECS side of things and it was only the Aframe side that was still broken/fighting the user.

If you want, we can go through this at (or just after) the weekly dev meetup today.

Thank you again for looking into this!

[HussainAther]

Would it make sense to focus debugging on when A-Frame physics takes ownership away from the user? I suspect there’s a state reset happening in updateRigidBody. Do you recall where the state enabling/disabling should happen?

EDIT: Never mind. Let me look into this further. Thanks...