Skip to content

Splitter interaction shadows flush child scrollbars near tile seams #158

Description

@nymph-ai

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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions