Relevant Konsole Settings:

Initial Size: 270 x 68
Scrollback: Fixed size 10000 lines

EDIT: the bug doesn't seem to have anything to do with zooming.

New reproducing Testcase:

STEPS TO REPRODUCE
1. open konsole
2. set scrollbar to 'hidden'
3. get some lines into the scroll buffer (e.g. `yes | head -n100`)
4. scroll a bit (using the touchpad)
5. stop scrolling
6. scroll a bit (using the touchpad)
7. scrollbar appears on the left side of the window

Tested different scroll methods:
- via Shift+Up, Shift+PgUp -- works as intended
- via Mouse Wheel -- works as intended
- via Touchṕad Two-Finger scroll -- scrollbar appears unexpectedly

I tried to find the first version in which this bug occurs:

Turns out this bug is not triggered by a specific konsole version.

This bug is only observable when using Qt5 5.14, on Qt5 5.13, this bug does not exist.

UPDATE

I tried to reproduce this issue today with latest konsole-git master, and try to find where this bug occurs:

When starting scrolling for the second time using the touchpad, TerminalDisplay::wheelEvent propagates the event to QScrollBar::event on line 2717 (https://github.com/KDE/konsole/blob/09cc4f6bb97d9133f075bcc0cbf07506fb5f61c5/src/TerminalDisplay.cpp#L2717).

In this case, the QScrollBar implementation further delegates to QWidget::event, which finally calls QWidget::setVisible(true).

This results in the scroll bar becoming visible unexpectedly.

UPDATE

I have found where the scrollbar is set to visible:

TerminalDisplay::wheelEvent(QWheelEvent) at TerminalDisplay.cpp:2717 calls _scrollBar->event(ev);
QScrollBar::event(QEvent) at qscrollbar.cpp:490 calls QAbstractSlider::event(event)
QAbstractSlider::event(QEvent) at qabstractslider.cpp:953 calls QWidget::event(e)
QWidget::event(QEvent) at qwidget.cpp:8662 calls wheelEvent((QWheelEvent*)event)
QScrollBar::wheelEvent(QWheelEvent) at qscrollbar.cpp:517 calls d->setTransient(false)
QScrollBarPrivate::setTransient(bool) at qscrollbar.cpp:230 calls q->show()
QWidget::show() at qwidget.cpp:7680 calls setVisible(true)

This looks like some parts of the internals of Qt5 changed with Qt5.14 which now result in the scrollbar to be visible. I will try to compare with the source code of Qt 5.13, since the scrollbar started appearing only after I updated to 5.14.

Created attachment 125626 [details]
Workaround Patch

I attached a patch that works around the issue by reapplying the scrollbar state (_scrollBar->setHidden(true)) every time an event is propagated to the scroll bar.

It's not beautiful, but it works, and should be a NOP in cases where this bug does not occur.

Created attachment 125627 [details]
QScrollBar diff between 5.13.2 and 5.14.0

I also attached a diff showing what changed in QScrollBar from Qt 5.13.2 to 5.14.0, which is what I suspect caused this bug to appear.

I have tested latest konsole master with 5.13.2, 5.14.0, and 5.14.1, and the bug appears in both 5.14.0 and 5.14.1, but not in 5.13.2

Added phabricator revision for this patch: https://phabricator.kde.org/D27110

I'm looking at this - currently can't reproduce - thanks for patch

(In reply to Ferdinand B from comment #3)
> Tested different scroll methods:
> - via Shift+Up, Shift+PgUp -- works as intended
> - via Mouse Wheel -- works as intended
> - via Touchṕad Two-Finger scroll -- scrollbar appears unexpectedly

Ok now I see this comment - I'll have to see if one my old laptops still works.

UPDATE:

I tried to reproduce this bug on a system other than my own now, and found the following:

- the bug only occurs on wayland
- the bug only occurs with touchpads (e.g. a synaptics laptop touchpad)
- the bug only occurs with Qt 5.14 or greater

Reproducing System Config:

- ArchLinux with sway, Qt 5.14 (my daily driver)
- Fedora KDE Rawhide (tested with [[ https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200428.n.0/compose/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-Rawhide-20200428.n.0.iso | 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.

I have also added a more detailed analysis of the bug to the phabricator revision linked above

Git commit c0aff2e90e2f827fee9f780603d740f83a5ba147 by Kurt Hindenburg, on behalf of Ferdinand Bachmann.
Committed on 04/07/2020 at 17:31.
Pushed by hindenburg into branch 'master'.

Fix scrollbar reappearing when using the touchpad (only on Wayland)

On Wayland, sometimes the scrollbar reappears on the left side of the
screen even when the scrollbar is set to 'hidden'.

- This happens when scrolling twice using the touchpad.
- This only happens on Wayland
- This only happens with Qt 5.14 or newer

This patch is a workaround for a change in Qt 5.14. Due "scroll phases",
scrollbars get set to visible when starting to scroll, and don't hide
themselves afterwards.
FIXED-IN: 20.08

https://invent.kde.org/utilities/konsole/-/merge_requests/127

M  +14   -3    src/TerminalDisplay.cpp
M  +4    -0    src/TerminalDisplay.h

https://invent.kde.org/utilities/konsole/commit/c0aff2e90e2f827fee9f780603d740f83a5ba147