When tiling is disabled, if I drag and drop a window over the top panel, the panel automatically comes back to the forefront and the app ends up with its titlebar behind the panel. This makes it very difficult to move the window back out from behind the panel-- currently, it looks like the easiest workaround is to maximize the window with Super-M and then un-maximize it with the mouse so it can be dropped somewhere else.
I can see a case for having windows fall behind non-extended panels (e.g. being partially overlapped by a dock), but it doesn't seem like I should be able to drag a window behind an extended panel, at least at the top of the screen. On GNOME, the window stops moving up when it hits the top bar. On Windows, a window stops moving down or to the side when the mouse cursor hits the taskbar (which ensures that somewhere the mouse cursor can grab is still exposed).
Determining the expected behavior for this might need @pop-os/ux involvement. Multi-monitor support might be a consideration when it comes to placing any kind of barrier there.
Floating tiling seems to have improved this by making it less likely a window is dropped where it can't be grabbed. It's still possible but hard to do.
When tiling is disabled, if I drag and drop a window over the top panel, the panel automatically comes back to the forefront and the app ends up with its titlebar behind the panel. This makes it very difficult to move the window back out from behind the panel-- currently, it looks like the easiest workaround is to maximize the window with Super-M and then un-maximize it with the mouse so it can be dropped somewhere else.
I can see a case for having windows fall behind non-extended panels (e.g. being partially overlapped by a dock), but it doesn't seem like I should be able to drag a window behind an extended panel, at least at the top of the screen. On GNOME, the window stops moving up when it hits the top bar. On Windows, a window stops moving down or to the side when the mouse cursor hits the taskbar (which ensures that somewhere the mouse cursor can grab is still exposed).
Determining the expected behavior for this might need @pop-os/ux involvement. Multi-monitor support might be a consideration when it comes to placing any kind of barrier there.