Separator stuck in "active" state when mouse is released over an iframe during drag

[dariosa]

Description

When dragging the separator (resize handle) and releasing the mouse button while the pointer is over a panel that contains an <iframe>, the separator gets permanently stuck in the "active" interaction state. The data-separator attribute remains "active" indefinitely instead of transitioning back to "inactive".
This is related to but distinct from #645 (which covered the hover state persisting). This issue is about the active drag state never clearing after a mouseup over an iframe.

Steps to Reproduce

1. Create a layout where at least one Panel contains an <iframe>
2. Press down on the Separator — it enters the "active" state
3. While holding the mouse button, drag the pointer over the iframe
4. Release the mouse button while the pointer is over the iframe
5. The separator remains in "active" state permanently — moving the mouse away does not clear it

Expected Behavior

Releasing the mouse button should transition the separator from "active" to "inactive", regardless of whether the pointer is over an iframe.

Actual Behavior

The separator stays stuck in "active" state. The data-separator attribute remains "active" and any associated visual styles (e.g. highlighted color) persist until the page is reloaded or the user clicks directly on the separator again.

[bvaughn]

I'm not able to reproduce the behavior described here in my test harness. Can you share a repro as either a Code Sandbox or a small GitHub project?

Update: I take this back. I am able to reproduce it, sometimes, if I move the pointer quickly.

[bvaughn]

For what it's worth, this code specifically is supposed to handle the case you're reporting:

react-resizable-panels/lib/global/event-handlers/onDocumentPointerMove.ts

Lines 23 to 55 in 5c13ebd

	case "active": {
	// Edge case (see #340)
	// Detect when the pointer has been released outside an iframe on a different domain
	if (
	// Skip this check for "pointerleave" events, else Firefox triggers a false positive (see #514)
	event.buttons === 0
	) {
	updateInteractionState({
	cursorFlags: 0,
	state: "inactive"
	});
	// Dispatch one more "change" event after the interaction state has been reset
	// Groups use this as a signal to call onLayoutChanged
	interactionState.hitRegions.forEach((hitRegion) => {
	const groupState = getMountedGroupState(hitRegion.group.id, true);
	updateMountedGroup(hitRegion.group, groupState);
	});
	return;
	}
	updateActiveHitRegions({
	document: event.currentTarget as Document,
	event,
	hitRegions: interactionState.hitRegions,
	initialLayoutMap: interactionState.initialLayoutMap,
	mountedGroups,
	pointerDownAtPoint: interactionState.pointerDownAtPoint,
	prevCursorFlags: interactionState.cursorFlags
	});
	break;
	}

[bvaughn]

I'm not sure if there's anything much I can do to fix this. Looks like neither "pointerleave" nor "pointerup" get dispatched in this case.

[bvaughn]

I think #689 captures the behavior in an e2e test. I'm not really sure of what I can do at the library level to fix this though.

[bvaughn]

I just noticed the 😕 reaction but I'm not sure how to interpret it. I would welcome suggestions or ideas about how to fix this if you have any? 😄

I'm not sure how this library can work around the absence of events that the browser should be emitting. From searching online, I see suggestions to temporarily disable pointer events for iframes on mouse-down, or overlay divs on top of iframes to capture the events– but a library like this can't do any of that. It would be far too invasive.

Best I can think of at the moment is to put a note in the "common questions" section of the docs but I realize that many people probably wouldn't even think to look there.

Again, suggestions (or help) would be welcome here. I'm just a single person trying to maintain this library in my spare time. 😄

[Vikx001]

Calling setPointerCapture on the separator element during pointerdown fixes this:

// in onDocumentPointerDown.ts, after focusing the separator element
current.separator.element.setPointerCapture?.(event.pointerId);

When pointer capture is active, the browser keeps routing pointermove and pointerup to that element even when the pointer moves over an iframe. The events still bubble normally to document, so all existing handlers work without any other changes. Pointer capture is also released automatically by the browser on pointerup, so no cleanup needed ig.

Tested locally — the separator correctly returns to inactive after releasing the mouse over an iframe. Atleast thats what i understood XDD

[bvaughn]

Thanks for sharing this finding, @Vikx001! It looks like that change does fix the e2e test I added above capturing the problem reported here, though it breaks another integration test ("pointer interactions › should not prevent click events if no drag occurs") so I'll still need to dig into that one. It seems like calling setPointerCapture prevents subsequent "pointerup" or "click" events from being called 🤔

This seems like a promising path forward though, regardless.

[bvaughn]

I think I can support both cases by not calling setPointerCapture until "pointermove"