Summary
A vertical scrollbar drawn flush against the right edge of a child tile loses the final few pixels of its hover/drag target to the adjacent horizontal splitter. Pressing that part of the thumb resizes the tiles instead of scrolling.
This reproduces with egui_tiles 0.17.0 and remains structurally present on current main / 0.17.1 at commit 51e1655.
Measured behavior
In a 1600x1000 tiled viewport whose left tile ends at x=750, the scrollbar has a 6px sense band at x=744..750:
| pointer x |
result |
| 741 |
outside the scrollbar sense band; no reaction |
| 745 |
scrollbar handle expands and drag scrolls correctly |
| 748 |
scrollbar does not hover; drag moves the tile splitter |
The overlap is therefore roughly the last 3px nearest the seam. Mouse-wheel scrolling is unaffected.
Why this appears to happen
Linear::horizontal_ui first calls tree.tile_ui for each child. It then registers each splitter across a full-height line_rect:
for &child in &visible_children {
tree.tile_ui(behavior, drop_context, ui, child);
// ...
}
let line_rect = Rect::from_center_size(
pos2(x, parent_rect.center().y),
vec2(
2.0 * ui.style().interaction.resize_grab_radius_side,
parent_rect.height(),
),
);
let response = ui.interact(line_rect, resize_id, egui::Sense::click_and_drag());
An egui ScrollArea inside the child has already registered its scrollbar interaction. Where the two sense rectangles overlap, the later splitter response wins the pointer.
Rerun makes this easy to hit because its design tokens deliberately set scroll.bar_outer_margin = 0.0, placing scrollbars flush against tiled viewport edges. The behavior also reproduces in a custom child that uses the same flush ScrollArea geometry, so it is not specific to Rerun content.
Expected behavior
The visible scrollbar thumb should retain its hover/drag target across its full sense band. The splitter can still own its gap and any non-content grab radius, but overlapping a visible child control should not silently turn a scroll drag into a resize drag.
Would you prefer this addressed by constraining the splitter interaction rectangle to the inter-tile gap, or through egui interaction priority/competition? I can help turn the measured case into an egui_tiles fixture once the intended policy is clear.
Downstream tracking: https://github.com/nymph-ai/nymphai/issues/1229
Summary
A vertical scrollbar drawn flush against the right edge of a child tile loses the final few pixels of its hover/drag target to the adjacent horizontal splitter. Pressing that part of the thumb resizes the tiles instead of scrolling.
This reproduces with egui_tiles 0.17.0 and remains structurally present on current main / 0.17.1 at commit 51e1655.
Measured behavior
In a 1600x1000 tiled viewport whose left tile ends at x=750, the scrollbar has a 6px sense band at x=744..750:
The overlap is therefore roughly the last 3px nearest the seam. Mouse-wheel scrolling is unaffected.
Why this appears to happen
Linear::horizontal_ui first calls tree.tile_ui for each child. It then registers each splitter across a full-height line_rect:
An egui ScrollArea inside the child has already registered its scrollbar interaction. Where the two sense rectangles overlap, the later splitter response wins the pointer.
Rerun makes this easy to hit because its design tokens deliberately set scroll.bar_outer_margin = 0.0, placing scrollbars flush against tiled viewport edges. The behavior also reproduces in a custom child that uses the same flush ScrollArea geometry, so it is not specific to Rerun content.
Expected behavior
The visible scrollbar thumb should retain its hover/drag target across its full sense band. The splitter can still own its gap and any non-content grab radius, but overlapping a visible child control should not silently turn a scroll drag into a resize drag.
Would you prefer this addressed by constraining the splitter interaction rectangle to the inter-tile gap, or through egui interaction priority/competition? I can help turn the measured case into an egui_tiles fixture once the intended policy is clear.
Downstream tracking: https://github.com/nymph-ai/nymphai/issues/1229