https://bugs.kde.org/show_bug.cgi?id=494699

Vlad <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vladsofronov7+6ygr0x0v@gmai
                   |                            |l.com

--- Comment #1 from Vlad <[email protected]> ---
Additional findings, following up on this report.

I can reproduce this 100% of the time, and have narrowed down the trigger
condition.

SETUP
2 monitors arranged vertically: Monitor B is positioned directly above Monitor
A.
Yakuake lives on Monitor A (the bottom one).

FINDINGS
- Disabling Monitor B (single-monitor setup) → bug disappears, drag-resize on
  Monitor A works normally.
- Moving Yakuake to Monitor B (the top monitor), with Monitor A still active
below it → bug disappears there too. The bug only affects a monitor that has
another monitor directly adjacent above it.
- Forcing the app through XWayland (QT_QPA_PLATFORM=xcb yakuake) does NOT
change the behavior. This makes the issue appear more likely to be
compositor-side than specific to Qt's Wayland backend.
- Shifting Monitor B horizontally while it still shares part of the vertical
  boundary with Monitor A → bug still occurs identically.
- Moving Monitor B completely away, so it no longer shares any horizontal
boundary with Monitor A → the snap-to-100% bug disappears and the window
becomes resizable again, BUT a new artifact appears: the window's vertical
position shifts unexpectedly during/after the resize.
- Workaround found: while holding the resize border to change Yakuake's height,
if the mouse cursor crosses the shared boundary into Monitor B's screen area
(the monitor above) during the drag, the resize completes correctly without
snapping to 100% height, but the window itself is moved onto Monitor B.

HYPOTHESIS
The findings suggest the issue is primarily related to output geometry rather
than to a particular rendering backend. Whether the underlying cause is in
KWin's handling of interactive resize near output boundaries or in how
Yakuake's special window type interacts with that logic is unclear, but the
monitor layout appears to be the deciding factor.

ENVIRONMENT
- Arch Linux
- KDE Plasma 6.7.2, Wayland session
- KWin 6.7.2
- Yakuake 26.04.3-1
- 2 monitors, vertical stack arrangement

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to