ContextMenu overlay does not show hover states

[zquestz]

Buttons inside the ContextMenu overlay do not show hover states. Clicks work correctly.

Reproduction:

Run the context_menu example:

cargo run --example context_menu

Right-click to open the menu, then hover over the buttons. No hover effect is displayed. For comparison, the "right click me!" button outside the context menu shows hover correctly.

Environment:

• iced_aw version: 0.13.0
• iced version: 0.14.0
• OS: Arch

[noamichael]

It seems the buttons in the context menu incorrectly have a disabled state.

I figured this out by adding a custom style for the buttons where I print out the status (Pressed, Active, Hover, or Disabled:

fn context_menu_button_style() -> impl Fn(&iced::Theme, button::Status) -> button::Style {
    move |theme: &iced::Theme, status: button::Status| {
        println!("Context menu button style called with status: {:?}", status);
        // other code...
    }
}

The only status the buttons will show are disabled:

Context menu button style called with status: Disabled

This is strange as the status is only ever disabled if there is no on_press action:

https://github.com/iced-rs/iced/blob/595af03a9f1806f1052685081e50909d596dcdc8/widget/src/button.rs#L342

let current_status = if self.on_press.is_none() {
     Status::Disabled
}

[genusistimelord]

im guessing we need to ensure they have an on_press event since iced has changed this.

[noamichael]

The current context_menu example does have on_press so there must be something else going on:

iced_aw/examples/context_menu.rs

Line 64 in 1346729

.on_press(Message::Choice1)

I was also able to recreate this in my test app. I might poke around and see if I can spot why this would happen.

[genusistimelord]

ok thank you for taking a look. its hard to tell what the issue is if it already has the on_press

[noamichael]

I updated the example locally to only have a single button to make debugging easier. I'm probably a bit over my head for this one, but what I've discovered is the issue is related to how the status of the button is unset during the draw function, so it falls back to disabled:

Note that the debug console shows status as None and we're within Button::draw. This is run right after the context menu is opened.

I set a breakpoint for where the button's status gets set (within Button::update), and for where the button gets drawn (within Button::draw). The update occurs before the draw, so the status should be set in theory, but then I checked (what I'm assuming to be) the addresses of the buttons from the debugger, and I noticed they seem to be different references:

# reference within `Button::update`
(iced_widget::button::Button<context_menu::Message, iced_core::theme::Theme, iced_renderer::fallback::Renderer<iced_wgpu::Renderer, iced_tiny_skia::Renderer> > *) 0x0000000139751de0

# reference within `Button::draw`
(iced_widget::button::Button<context_menu::Message, iced_core::theme::Theme, iced_renderer::fallback::Renderer<iced_wgpu::Renderer, iced_tiny_skia::Renderer> > *) 0x000000014006c320

So I'm wondering if

• A. the references are different because the two calls are happening within different frames being drawn, hence it's a new instance of the button
  • In this case, the fix might be to ensure the status is determined before the first call to draw
• B. some kind of clone of the content is being done somewhere (I think A is more likely)

Would anyone with more insight into the rendering lifecycle have suggestions on what to check next?

[genusistimelord]

@noamichael can you verify if the fix he did does indeed fix the issues for you?