Resize Handle Interaction#

The resize handle system in Element Web (matrix-react-sdk) is split into two layers: a thin presentational React component (ResizeHandle.tsx) that renders the DOM, and a separate Resizer class that drives all interaction logic. Understanding where each concern lives is essential when debugging hover, focus, or drag behavior.

Component and Resizer Architecture#

ResizeHandle.tsx is a stateless component. It emits no events and has no keyboard handlers, ARIA attributes, or tabIndex — it purely applies CSS class names (mx_ResizeHandle, mx_ResizeHandle--horizontal, mx_ResizeHandle--vertical, mx_ResizeHandle_reverse) based on props 1.

All interaction is delegated to src/resizer/resizer.ts. The Resizer class attaches a mousedown listener to the container (not the handle element itself) 2. On a matching left-button click:

1. event.preventDefault() is called to suppress the browser's native drag/text-selection behavior 3.
2. A resizer-resizing class is added to the container 4.
3. mousemove and mouseup listeners are added to document.body; mouseleave is added to document to cancel the drag if the cursor leaves the window 5.

CSS Pseudo-Class Behavior#

Base cursor and layout styles live in _ResizeHandle.pcss — no :hover, :focus, or :active styles are defined there 6. Visual hover feedback is added at the usage site via ::before pseudo-elements:

Each inserts a 4 px wide × 64 px tall rounded bar at 0.8 opacity using $primary-content colour.

No :focus or :active CSS rules are defined for mx_ResizeHandle anywhere in the codebase — the handle is not focusable (no tabIndex) and carries no focus styling.

Known Pseudo-Class Conflict Issues#

Two confirmed bugs (Firefox 152, reported 2026-07-28) illustrate how the pure-CSS :hover approach interacts badly with pointer capture:

• Hover stuck after cursor leaves window (element-web#34431): When the cursor exits the browser window while still over the handle, the browser's CSS :hover state is not cleared because the mouseleave event fires on document (which is used to cancel the drag), but the element's :hover pseudo-class is only cleared when the cursor actually moves off the element — which never happens if the window loses pointer capture first.

• Hover lost after click (element-web#34432): After clicking the resizer, the :hover style no longer re-applies on subsequent hover. The root cause is linked to event.preventDefault() in onMouseDown 3: calling preventDefault() on mousedown suppresses the default focus-management step that the browser performs, which in some browsers causes the element to enter an internal state where the :hover pseudo-class is not re-evaluated until focus moves elsewhere.

Newer Separator Implementation (element-web)#

A parallel, more modern implementation exists in element-web for the room list separator (distinct from the legacy Resizer class). Key design decisions made to avoid the pseudo-class conflicts above:

• Pointer events replace mouse events: onPointerDown / onPointerMove / onPointerUp are used to disambiguate click from drag via a MouseClickHandler utility, without calling preventDefault() on the initiating event 10.
• CSS :focus-visible replaces JS focus tracking: The what-input library and onFocus/onBlur handlers were removed 11. The separator now uses :focus-visible natively, animating a 1 px border to 2 px on keyboard focus.
• display: none prevents spurious hover: Where the separator should be non-interactive, it is hidden with display: none rather than opacity: 0, so the browser cannot match :hover against a visually hidden hit target 12.
• Hit region sizing: The absolutely positioned hit container was reduced from 20 px to 10 px wide to prevent the hover overlay from capturing events intended for an adjacent scrollbar 13.

Key Files#