pop-os / cosmic-comp

Compositor for the COSMIC desktop environment
GNU General Public License v3.0
479 stars 86 forks source link

Parts of menus that are over a panel aren't selectable #418

Open git-f0x opened 6 months ago

git-f0x commented 6 months ago

This occurs regardless of panel configuration (other than autohide, since the panel goes away). If this is more related to cosmic-comp, feel free to move this there.

wash2 commented 6 months ago

what is an example of the issue? I think ideally in the case of a panel that doesn't hide, popups should probably be constrained so that they don't overlap the panel.

git-f0x commented 6 months ago

Some apps have drop-down menus from the sides, so this can make certain options non-clickable when maximized (or if the menu is long enough). It would probably be more desirable that the popup overlaps the panel, so that it doesn't lead to unexpected popup placement. screenshot-2024-04-11-09-05-56 screenshot-2024-04-11-09-12-53

wash2 commented 6 months ago

This might also happen if the menus are subsurfaces instead of popups. I don't believe they will receive pointer motion events when they are outside the parent window. If they are not being constrained by cosmic-comp, I would guess they might be.

wash2 commented 6 months ago

Hmm, actually testing this locally with inkscape it seems to be using regular popups.

git-f0x commented 6 months ago

The drop-down menu of the app in the second screenshot (and other Xwayland apps) didn't previously receive pointer events outside the window, but that has since been fixed in cosmic-comp (maybe around a month or two ago). So this is some interaction with the panel specifically (since pointer events for menus outside the window are received for both Wayland and Xwayland windows when not overlapping a panel).

wash2 commented 6 months ago

Ya, this is probably related to how cosmic-comp orders the surfaces that it sends pointer events to. I can transfer it there.

ids1024 commented 3 months ago

It would be good if surface_under (used for pointer/touch input) and workspaces_elements (used for rendering) could share logic for the z-order of all the elements in some way, so they don't have to duplicate that and it can't be inconsistent.

vadimk1337 commented 1 month ago

Essentially, this menu in Google Chrome shouldn't go beyond these boundaries at all. Here's a comparison with GNOME. Yes, they should be clickable, of course, but please also look into this bug

image Screenshot from 2024-09-05 00-23-48