[Bug] InteractiveOrientationWidget stuck in active state

[Antti-Palola]

Bug description

InteractiveOrientationWidget stops the main view from working anymore. Can be fixed by clicking on the widget again.

Steps to reproduce

Go to https://kitware.github.io/vtk-js/examples/InteractiveOrientationWidget.html

• Start a quick mouse drag from orientation widget and end the drag outside the widget in the canvas area.
• OrientationMarkerWidget triggers orientation change but keeps active state
• Try to rotate model
• Model is stuck

Detailed Behavior

This often happens if you want to spin your model around and start the drag too close to the widget.

vtk-js/Sources/Widgets/Widgets3D/InteractiveOrientationWidget/behavior.js

Line 32 in 4691eea

if (

getActive returns true and thus the mouse event is aborted.

Expected Behavior

The widget never gets stuck in active mode.

The same kind of behavior can be caused by starting a normal model rotate and ending the drag outside browser: model will stay in rotation mode. Could this be improved by ending LeftButtonPress event on "drags outside"? I guess this event is somehow virtually created from pointerup/pointerdown events.

Environment

• vtk.js version: latest
• Browsers: any
• OS: any

[finetjul]

I do not reproduce the error on Windows/Chrome + Windows/Firefox. Can you record a video with your mouse cursor ?

[koskimas]

Here you go.

Macos 14.6.1
Chrome 29.0.6668.70

Screen.Recording.2024-10-11.at.9.38.26.mov.webm

[finetjul]

Can you confirm it is a mac only problem ?

Do you reproduce the issue with a mouse ? touch pad ?
(I know there are some subtle differences with Mac mouse events)

[koskimas]

I'm pretty sure this happens on linux and windows too, but we'll test other OSes and pointer devices on that same example and get back to you.

[daker]

OS: Windows 11
Nvidia GPU
Mouse

Enregistrement.de.l.ecran.2024-10-11.101047.mp4

[finetjul]

I still can't reproduce on my Windows laptop :-(

[daker]

This happen on both FF & Chrome, note that i can still zoom in/out with the mousewheel but not able to rotate the cone

[Antti-Palola]

Can this be approached with a more code review heavy debugging. Wherever the internals of the mouse press handlers are created, is there a possibility that the mouseup is somehow misplaced?

[koskimas]

I don't have a reproduction since I don't know exactly how, but it seems to happen even without touching the orientation widget. The view is stuck several times a day on my normal usage.

Four other people at our company have reported this issue.

[Antti-Palola]

Found an easy way to cause sticking. If you run the example locally after editing the widget bounds to not be 0.45 times the input bounds, it's like 50% times stuck when dragging from model and mouseUpping on top of indicator.

vtk-js/Sources/Widgets/Widgets3D/InteractiveOrientationWidget/helpers.js

Lines 34 to 39 in 4691eea

	export function createInteractiveOrientationWidget(bounds) {
	const widget = vtkInteractiveOrientationWidget.newInstance();
	widget.placeWidget(bounds);
	widget.setBounds(bounds.map((v) => v * 0.45));
	return widget;

export function createInteractiveOrientationWidget(bounds) {
  const widget = vtkInteractiveOrientationWidget.newInstance();
  widget.placeWidget(bounds);
  widget.setBounds(bounds.map((v) => v));

  return widget;
}

stuck_interactiveOrientationWidget_safari.webm

MacOS 14.6, Safari 17.6 & FF 130 & Chrome 129

[floryst]

I've isolated the problem. There are two parts to it: how the orientation widget operates with its own renderer, and how the widget manager behaves when there are multiple renderers.

In the orientation widget example, there are two renderers: the primary one that fills the screen and contains the cone. This renderer sits in the background. The second renderer takes up a small portion of the lower left part of the viewport and contains the widget. Importantly, the boundary of this smaller renderer is larger than the orientation widget.

The vtkWidgetManager is associated to the orientation widget renderer. This means widget selection and deselection events only occur for mouse actions inside the corner renderer. When a mouse move event occurs on top of the widget, the widget is activated. When the mouse moves off of the widget but remains inside the corner renderer, the widget is deactivated.

The bug manifests when the mouse moves fast enough such that the first mouse move event occurs on top of the widget, then the next mouse move event occurs outside of the small renderer. Since no mouse move event occurred inside the small renderer but off the widget, the widget is not deactivated. No clicking is needed; just position the mouse on the widget, then move the mouse as quickly as you can to the cone. If successful, you can't move the cone anymore.

One possible solution to this is in handleEvent. If the event should not be handled, then deactivate all widgets associated with the widget manager. (Or at minimum, deactivate all widgets if the mouse event is on a different renderer.) I think this makes sense; if you're interacting on one renderer, you don't expect to be interact with widgets on another renderer.

vtk-js/Sources/Widgets/Core/WidgetManager/index.js

Lines 186 to 196 in 4691eea

	const handleEvent = async (callData, fromTouchEvent = false) => {
	if (
	!model.isAnimating &&
	model.pickingEnabled &&
	callData.pokedRenderer === model._renderer
	) {
	const callID = Symbol('UpdateSelection');
	model._currentUpdateSelectionCallID = callID;
	await updateSelection(callData, fromTouchEvent, callID);
	}
	};

.

[jord1e]

@floryst Do you know if there is a workaround for this issue at the moment?

I guess the "orientationMarkerWidget" is necessary to register the click, so we need its renderer (which causes the problem?):
widgetManager.setRenderer(orientationMarkerWidget.getRenderer());

Firefox (latest)/W10/vtk.js latest (although its been a problem for a while now)

[floryst]

@jord1e you can try out #3204 to see if it fixes the issue for you. There is an alternative that might be better overall, but #3204 is the easiest (currently untested) fix that I can come up with.