Clamp panel rects to visible bounds#8056
Conversation
|
Preview available at https://egui-pr-preview.github.io/pr/8056-fix-panel-overflow-rect View snapshot changes at kitdiff |
|
Could you maybe make a regression test for this in |
Test that SidePanel and TopBottomPanel response.rect and response.interact_rect are clamped to visible panel bounds when content overflows. See: emilk#8056 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
054cb04 to
3bc91e9
Compare
Panel `response.rect` and `response.interact_rect` were not clamped to visible panel bounds when content inside overflowed, causing callers to receive an oversized rect that broke pointer hit-testing, separator placement, and available_rect advancement (pushing CentralPanel off-screen). Fix: intersect both rects with `panel_rect` in `show_inside_dyn`, and intersect `response.rect` with `available_rect` in `show_dyn`. Regression test + visual snapshot included. See: emilk#8056 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
94c4623 to
fa39354
Compare
Panel `response.rect` and `response.interact_rect` must be clamped to visible panel bounds even when content inside overflows. Before the fix callers received an oversized rect that broke pointer hit-testing, separator placement, and available_rect advancement. See: emilk#8056 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Intersect `response.rect` and `response.interact_rect` with `panel_rect` in `show_inside_dyn`, so callers receive correctly-sized rects that match the visible panel edge. Without this, overflowing content caused the returned rect to exceed the panel bounds, breaking pointer hit-testing and pushing CentralPanel off-screen. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
fa39354 to
ffdf956
Compare
|
Sorry for this mess with history. perhaps test is added. I checked up screenshots - sort of reproducing the ptoblem |
|
Related issues that may benefit from or overlap with this fix:
|
|
This is necessary to prevent a regression introduced in v0.34, where the left panel in my application starts growing automatically: Peek.2026-04-09.02-18.mp4 |
|
This produced some regressions in some existing screenshot tests. I think we may need to dig a bit deeper here. Did anyone do a git bisect to see when this was introduced? Or is this because of a difference in behavior between |
|
|
||
| let inner_response = self.show_inside_dyn(&mut panel_ui, add_contents); | ||
| let rect = inner_response.response.rect; | ||
| let rect = inner_response.response.rect.intersect(available_rect); |
There was a problem hiding this comment.
Is this part necessary? inner_response.response.rect is already clamped by show_inside_dyn, which we call directly above this line.
A subset of emilk#8056.
Fixes #8055.
When panel contents overflow beyond the visible clamped bounds, the panel response can become larger than the actual visible panel. That oversized response was then reused by integrations for pointer hit-testing, and its rect was also reused internally for cursor advancement, stored panel state, separator painting, and top-level panel allocation.
This change clamps the outward-facing panel response back to the visible panel bounds with
intersect(panel_rect), for bothresponse.rectandresponse.interact_rect. The fix is applied to bothSidePanelandTopBottomPanel, so callers using the returned panel response do not inherit oversized clipped-child bounds.I verified this against a Bevy + bevy_egui integration where a resizable panel with clipped overflow content incorrectly blocked scene interaction and displaced its effective boundary. After this change, the panel hit area and boundary stay aligned with the visible panel edge.