Search Issue Tracker
By Design
Votes
0
Found in
2018.1.0a5
2018.2.1f1
Issue ID
1071920
Regression
Yes
Snapcam GUI elements not responding to input in Scene View when view is not set to 2d
To reproduce:
1. Open my attached project "SnapcamRepro, demo Scene
2. Make sure Scene view is set to 3d
3. Try interacting with settings button (cogwheel at bottom right)
Expected: GUI elements react to user no matter the 2d/3d setting
Actual: GUI elements do not respond to interactions when not in 2d mode
Reproduced in: 2018.1.0a5, 2018.1.9f2, 2018.2.8f1, 2018.3.0b1
Not reproduced in: 2017.2.3p4, 2017.4.11f1, 2018.1.0a4
Note: Snapcam Asset Store page:
https://assetstore.unity.com/packages/tools/level-design/snapcam-navigation-studio-99523
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Highlighter.Highlight does not find window when using class name as window title
- Highlighter.Highlight highlights a different component when multiple components have the same property path
- Highlighter.Highlight does not find elements in an array or list when the array or list is collapsed
- [URP][NRP] RenderPass, BeginSubPass, and EndRenderPass errors are thrown when Native RenderPass is enabled
- D3D11 swapchain error pop-up appears and the Editor shuts down when Generating Lighting with Probe Volumes present
Resolution Note (2018.3.X):
The problem here is that the package implicitly relies on the call order of callbacks registered with onSceneGUIDelegate. It is mere happenstance that the code in the package did not produce an error up to this point. I'm not familiar with this package, but the implementation in ViewNavigator looks like user error, since it indiscriminately uses the mouse up event irrespective of whether it originally consumed the MouseDown event. The package author needs to do a couple of things:
- Register a single scene GUI delegate entry point for their overlay, where overlay controls are drawn first, and then all other clicks through to the scene are processed (ensures overlay controls have the opportunity to be first responders)
- When consuming an arbitrary mouse down event (i.e. something that wasn't captured by some control in the overlay), they should set GUIUtility.hotControl to some passive/permanent control ID value when the Down event is used, only using the Up event if that ID still has hotControl (see key-event-based examples in https://github.com/Unity-Technologies/UnityCsReference/blob/master/Editor/Mono/SceneView/CameraFlyModeContext.cs, which is used in e.g., https://github.com/Unity-Technologies/UnityCsReference/blob/31c7ca85bcc43ef4258c2a216b195ad1d6e59948/Editor/Mono/SceneView/SceneViewMotion.cs)