Ui::interact's Response hover detection is incorrect

[Adanos020]

Describe the bug

Since I upgraded my crate egui_dock to egui 0.27, the Responses of all tab close buttons I allocated with Ui::interact "thinks they're being hovered and clicked always when I do these things to their corresponding tabs, even outside those close buttons.

In the screenshot below, my pointer (invisible here, apologies for that) is on the Style Editor tab title, and you can see that the close button is highlighted:

I double-checked to confirm that this did not happen with egui 0.26 and only appeared after I changed it to 0.27.

To Reproduce

Steps to reproduce the behavior:

1. Clone this branch.
2. Run cargo run --example hello.
3. Hover and click on any tab that has a close button, outside that button.
4. Observe that the close button is highlighted and the tab closes after being left-clicked.

Expected behavior

In this particular scenario: tab close buttons should only say they're hovered/clicked when the Rect I allocated one with does indeed contain the mouse pointer.

Additional context

According to the debugger, the close button's Response does indeed think it's both being hovered and containing pointer.

[YgorSouza]

I think this is due to the interact logic changing in #4026. You are using the same Id for the tab and the close button, but egui doesn't detect an Id clash because the clash detection checks if one of the rects contains the other, which it does in this case.

egui/crates/egui/src/context.rs

Lines 939 to 945 in 4d4cb3d

	// it is ok to reuse the same ID for e.g. a frame around a widget,
	// or to check for interaction with the same widget twice:
	let is_same_rect = prev_rect.expand(0.1).contains_rect(new_rect)
	|| new_rect.expand(0.1).contains_rect(prev_rect);
	if is_same_rect {
	return;
	}

(Maybe this || should be && instead? The variable name and the comment seem to disagree on that)

If you offset the close button slightly (e.g., by 1 point), egui is able to see the clash.

M src/widgets/dock_area/show/leaf.rs
@@ -588,7 +588,7 @@ impl<'tree, Tab> DockArea<'tree, Tab> {
 
         let close_response = show_close_button.then(|| {
             let mut close_button_rect = rect;
-            close_button_rect.set_left(text_rect.right());
+            close_button_rect.set_left(text_rect.right() + 1.0);
             close_button_rect =
                 Rect::from_center_size(close_button_rect.center(), Vec2::splat(close_button_size));

So I think you have to use with to give the close button a different Id, but I tried that and now the button doesn't detect clicks at all, presumably because it is behind the other Rect. I'm not sure what to do about this since I haven't read the entire code, but I hope this helps.

[Adanos020]

@YgorSouza Thanks for the reply. Yeah, I have tried using a different Id for the close button and had the same observations. I'll try digging further into this on my end and let you know of any progress.

[Adanos020]

I have found a fix. I made the close button Rect not overlap with the tab Rect by just putting one next to the other instead of one inside the other. Tabs and close buttons are now usable.

I think the new interact logic simply exposed a bug in my code. Thank you again for helping me with that!

[happydpc]

I think the new interact logic simply exposed a bug in my code. Thank you again for helping me with that!

The new interact logic make a difference, that the interaction depends on the interact function order. If there is an overlap, the top most one's "interact" should put at the end.

[Adanos020]

@happydpc Yeah, this code became quite complicated so I didn't notice the ordering error.