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

--- Comment #11 from Jakob Petsovits <[email protected]> ---
Digging into KWin code that I've been so far unfamiliar with.

So from my debug output, I can tell that Window::setVirtualKeyboardGeometry()
is getting called correctly. With Kate as my input method trigger window, and
Konsole as my incorrectly-cropped window upon getting focus:

* Touch Kate's text field.
* Kate remembers original window size as `m_keyboardGeometryRestore`. OSK pops
up and Kate effectively resizes to get shorter.
* Click on Konsole titlebar.
* `InputMethod::setTrackedWindow()` switches from Kate to Konsole.
* `InputMethod` calls `setVirtualKeyboardGeometry()` on the Kate window with an
empty rect. Kate restores its original size.
* `InputMethod` calls `setVirtualKeyboardGeometry()` on the Konsole window with
the (still) currently open Plasma Keyboard window geometry.
* Konsole, which had not been resized at all so far, remembers its original
window size as `m_keyboardGeometryRestore`. Konsole now resizes to get shorter.
* The OSK disappears.
* `InputMethod` calls `setVirtualKeyboardGeometry()` on the Konsole window with
an empty rect. Konsole restores its original size.

When I say "Konsole restores its original size", then I mean
`Window::moveResize()` is called with the correct (original, taller) geometry,
and then `moveResize()` is not anymore. So why do we still end up with an
incorrectly short window?

I don't fully understand what's going on. But it looks like it might be related
to the window resizing to a shorter height, and immediately resizing back to a
taller height. Here are three calls that seem relevant.

* When Konsole becomes the tracked window and the OSK is still shown (from Kate
earlier), `XdgSurfaceWindow::moveResizeInternal()` is called with a rectangle
of height 706. The current (original) height is 945. The two window sizes
differ, so `XdgSurfaceWindow::moveResizeInternal()` calls `scheduleConfigure()`
which sets off a timer. This will call `XdgSurfaceWindow::sendConfigure()` at
when the event loop next gets to it.

* Soon after, the OSK is hidden and the Konsole window restores its original
geometry. `XdgSurfaceWindow::moveResizeInternal()` is called with a rectangle
of height 945. The current (still unchanged!) height is also 945. Because the
requested size and current size are the same,
`XdgSurfaceWindow::moveResizeInternal()` calls
`WaylandWindow::updateGeometry()` instead, which looks like it's just meant for
moving the window here. It determines that geometries did not change (both are
height 945), and returns.

* Eventually, a commit happens. `XdgToplevelWindow::handleRoleCommit()` is
called on the Konsole window. `oldWindowGeometry` has a height of 945, as
expected. However, the newly assigned `m_windowGeometry` (coming from
`m_shellSurface->xdgSurface()->windowGeometry()`) now has the shorter height of
706. The window now gets resized to this shorter geometry and the original
height is lost.

How did that shorter height end up in there? I don't know yet, but it feels
like I'm close to understanding what's happening.

The requested window geometry during the commit seems to come from
`XdgToplevelWindow::sendRoleConfigure()`, which is what gets called on the
scheduled timer sometime after the original resize to shorter height 706. It
sources its geometry from `Window::moveResizeGeometry()`, which gets set
immediately by `Window::moveResize()`. I could imagine a sequence like this:

* `Window::moveResize()` sets shorter `moveResizeGeometry` rect with height
706. (`clientGeometry` rect still has height 945.)
* `XdgSurfaceWindow::moveResizeInternal()` schedules the configure timer.
* Configure timer triggers, configure event with height 706 is queued.
* `Window::moveResize()` sets original rect with height 945.
* `clientGeometry` rect still has height 945, so no configure event gets
scheduled.
* Commit happens, sources its new geometry from the configure event, and
`XdgToplevelWindow::handleRoleCommit()` sets all internal window geometry
(incl. `clientGeometry`) to height 706. Where it remains.

If this is what's happening, let's see if I can fix it with a one-liner. If
not... well, let me give it a shot.

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

Reply via email to