- Shipped
- September 5, 2026 at 2:15 AM UTC
- Author
- Kamo
- Commit
- 1973b19
The label was the browser's native `title` box: unstyled, and put wherever the other 291 hover targets in this chrome use, arrow and all. A head is not a normal hover target, so the tooltip is driven rather than triggered. MUI's own listeners are all off: the element it would bind them to is a zero-sized transform wrapper nothing can hover, and its touch long-press is the same gesture that opens the head's context menu. The stage owns one shared popper, opens it off HexHead's pointer enter/leave, and closes it on any press — a label hanging off a head being flung across the screen is not a label. A 400ms trail of flashing labels. The anchor is a virtual element reading the head's motion values on every call, not the DOM node. Heads move by writing their transform straight to the DOM with no React render in between, so a rect measured at open goes stale the moment a cluster reflows around a newly opened window; Popper is nudged to re-run whenever those values change. Placement is decided from where the head is, by placeTooltip: open away from the nearer horizontal edge, and for a head in the outer third of the screen align the tooltip's near edge to it so it grows inward instead of being shoved back on screen. Popper's flip and preventOverflow stay underneath as the safety net, on the viewport with the same 8px keep-out band the context menu uses — they cover what geometry alone cannot, a title wider than the space the placement leaves. Verified in Chrome, not only in jsdom: eight head positions (four corners, the centre, a 90-character title in the corner, and two heads dragged off the edge) across a 1200x800 and a 480x900 viewport, all sixteen labels fully inside the margin; and a head moved 250x120px by motion value alone, with the label tracking it to the pixel.