Looks fine - thanks - I'll commit shortly

I'm having problems updating my laptop - can anyone confirm the issue and fix?

I have looked at this a bit more today, in order to help people reproduce this:

• the bug only appears on Wayland, not on X11 or XWayland

when looking at the differences between the QWheelEvents between X11 and Wayland, I noticed that the Qt::ScrollPhase of the events is different!

• Mouse scrolling on Wayland: phase is always 0 (NoScrollPhase, phase not supported)
• Touchpad scrolling on Wayland: phase is 1, then 2, then 3 (ScrollBegin, ScrollUpdate, ScrollEnd)
• Mouse scrolling on X11: phase is always 0
• Touchpad scrolling on X11: phase is always 0

This is most likely what triggers the scrollbar becoming visible, because of this code in qscrollbar.cpp in Qt 5.14

void QScrollBar::wheelEvent(QWheelEvent *event)
{
    event->ignore();
    bool horizontal = qAbs(event->angleDelta().x()) > qAbs(event->angleDelta().y());
    // The vertical wheel can be used to scroll a horizontal scrollbar, but only if
    // there is no simultaneous horizontal wheel movement.  This is to avoid chaotic
    // scrolling on touchpads.
    if (!horizontal && event->angleDelta().x() != 0 && orientation() == Qt::Horizontal)
        return;
    // scrollbar is a special case - in vertical mode it reaches minimum
    // value in the upper position, however QSlider's minimum value is on
    // the bottom. So we need to invert the value, but since the scrollbar is
    // inverted by default, we need to invert the delta value only for the
    // horizontal orientation.
    int delta = horizontal ? -event->angleDelta().x() : event->angleDelta().y();
    Q_D(QScrollBar);
    if (d->scrollByDelta(horizontal ? Qt::Horizontal : Qt::Vertical, event->modifiers(), delta))
        event->accept();

    if (event->phase() == Qt::ScrollBegin)
        d->setTransient(false);
    else if (event->phase() == Qt::ScrollEnd)
        d->setTransient(true);
}

note the check of event->phase() near the bottom. d->setTransient(false) subsequently calls q-show(), which makes the scrollbar visible.

I wasn't able to debug this yet, but I think the scroll phase for wayland was just not yet implemented yet for Qt 5.13.2, since the code that checks the phase and calls q->setTransient(false) is also in 5.13.2, but doesn't get run there.

Reproducing System Config:

• ArchLinux with sway, Qt 5.14 (my daily driver)
• Fedora KDE Rawhide (tested with nightly from 2020.04.28) note: this starts KDE in X11 by default, need to install plasma-workspace-wayland, exit the X11 session, and run startplasma-wayland on a tty to get KDE in wayland mode

most likely, any system with Wayland and Qt 5.14 should do, but these are the two I tested it with.

I didn't find a distro yet that ships a working wayland and Qt 5.14 on their live install media, so this convoluted testing setup is all I have as of now. Fedora Workstation Rawhide *should* work directly in the Live ISO, but the current nightly has a broken GDM and I haven't found a working one yet, so I tried the KDE variant.

Any chance you could move this patch to https://invent.kde.org/kde/konsole/-/merge_requests/? See https://community.kde.org/Infrastructure/GitLab

In D27110#671177, @ngraham wrote:

Any chance you could move this patch to https://invent.kde.org/kde/konsole/-/merge_requests/? See https://community.kde.org/Infrastructure/GitLab

sure. I just didn't know the GitLab existed until today.

Done: Merge Request Link

Cool, thanks! Can you Abandon this patch then?