Mouse scrolling is broken

[melroy89]

Steps to reproduce

1. Open any chat
2. Try to use your scroll-wheel, to scroll up or down

Expected behaviour

Scrolling within the message window.

Actual behaviour

Telegram desktop doesn't respond to any scroll wheel action.

Operating system

Linux Mint 20.2 (Ubuntu based)

Version of Telegram Desktop

3.2.4

Installation source

Static binary from official website

Logs

No response

[ilya-fedin]

• Open any chat

• Try to use your scroll-wheel, to scroll up or down

Works like a charm. Looks like these steps aren't right.

[melroy89]

Hmm.. restarting Telegram fixed the problem. I could still type messages.

Is there some kind of crash report or logging file I could refer to?

EDIT: I found /home/<user>/.local/share/TelegramDesktop/log.txt file..

[melroy89]

The log file (log.txt) gets overridden.. Maybe you should store at least the current log AND ALSO the previous log file.

[ilya-fedin]

Nothing regarding scrolling is logging, it's something handled at toolkit level, not at app level

[jprando]

happened here with me too.

what I noticed is that the problem is intermittent, when the scroll does not work, I noticed that the mouse icon is different when it is over the application, and when the mouse icon is not different (from other apps) the scroll works in desktop telegram

I'm using the binary version available here on github in release v3.2.4 Pop!_OS 21.04 x64 Gnome 3.38.5 X11

[ilya-fedin]

Without a reliable way to reproduce, it's unlikely to be fixed

[jprando]

Without a reliable way to reproduce, it's unlikely to be fixed

yes, i'll keep an eye out here and if i can find a way to reproduce it, i'll share it here 😉

[melroy89]

@ilya-fedin yes, you could also think along how to debug this issue better.

[ilya-fedin]

@danger89 I don't imagine how this could happen and how to debug this, tdesktop just reacts to mouse events sent by Qt. I have a feel this is a Qt bug.

[AndreyKopeyko]

I have the same problem running 3.2.2 and 3.2.5 versions.

version 3.2.5 works for while after start, but some moment later wheel scroll becomes broken.

[AndreyKopeyko]

@danger89 I don't imagine how this could happen and how to debug this, tdesktop just reacts to mouse events sent by Qt. I have a feel this is a Qt bug.

It should happened in 3.1.8 version also if it was a Qt bag. But 3.1.8 scrolls nicely. No update of Gt libs on my laptop happened.

[ilya-fedin]

Qt was updated in 3.2.0

[AndreyKopeyko]

Without a reliable way to reproduce, it's unlikely to be fixed

How to reproduce:

1. install & start telegram desktop 3.2.5 - wheel scroll will work
2. put your note asleep - just close the lid
3. after awake - wheel scroll fails ;-(

Ubuntu 20.04.3 LTS libqt5gui5:amd64 5.12.8+dfsg-0ubuntu1

[ilya-fedin]

libqt5gui5:amd64 5.12.8+dfsg-0ubuntu1

tdesktop doesn't use your system Qt, it has Qt 6.2 embedded in the binary

[ilya-fedin]

2. put your note asleep - just close the lid

Can you be more specific - you mean suspend or hibernation? I don't have any action assigned to the lid.

[AndreyKopeyko]

1. put your note asleep - just close the lid

Can you be more specific - you mean suspend or hibernation? I don't have any action assigned to the lid.

suspend. No hibernation.

[ilya-fedin]

suspend. No hibernation.

Sorry, but I can't reproduce :( Works like a charm after suspend on my hardware.

[melroy89]

Qt was updated in 3.2.0

This could be why..

Maybe build a debug app (if possible, so we can catch any eerros)? Or did you see anything strange in the telegram desktop log.txt?

[AndreyKopeyko]

suspend. No hibernation.

Sorry, but I can't reproduce :( Works like a charm after suspend on my hardware.

Sorry indeed. How can I get additional info for you? Does desktop write some logs I can send you back?

[ilya-fedin]

Maybe build a debug app (if possible, so we can catch any eerros)? Or did you see anything strange in the telegram desktop log.txt?

I don't imagine how a debug build would help, this is not a crash, so debug symbols won't help. log.txt won't help either since, as I said previously, nothing regarding scrolling is logged.

How can I get additional info for you?

I don't know :(. If this is a Qt bug, only Qt developers know how to debug this...

[melroy89]

yea I could find some debugging techniques within the Qt docs: https://doc.qt.io/qt-5/debug.html

Just maybe QT_DEBUG_PLUGINS=1 environment variable could help... Maybe..

[ilya-fedin]

All QT_DEBUG_PLUGINS=1 does is outputs debug info about plugins loading

[ilya-fedin]

maybe QT_LOGGING_RULES='*.debug=true' would help, I'm not sure...

[AndreyKopeyko]

suspend. No hibernation.

Sorry, but I can't reproduce :( Works like a charm after suspend on my hardware.

It solidly happens if notebook was suspended for about 1 hour - the way from home to office.

[AndreyKopeyko]

QT_LOGGING_RULES='*.debug=true'

It produces a lot of output. Hope my SSD is enough to accommodate all of them until scroll freezes...

[AndreyKopeyko]

maybe QT_LOGGING_RULES='*.debug=true' would help, I'm not sure...

Pls take a look in the log - https://dev.kopeyko.ru/tmp/telegram-v3.2.5.debug20211119.output

I started telegram as

kaa@MRGnb2:~/tmp$ QT_LOGGING_RULES='*.debug=true' telegram 2>&1 |tee telegram-v3.2.5.debug20211119.output

All day it work great, but finally wheel scrolling got frozen - after note spend about 45 minutes in suspend mode (the way from office to home) :-(

Hope it'll help you to investigate the problem.

[ilya-fedin]

Pls take a look in the log - https://dev.kopeyko.ru/tmp/telegram-v3.2.5.debug20211119.output

I see input device re-detection at line 87810 and no scroll wheel events logged since then. I don't know when it happened though since the log has no timestamps.

[AndreyKopeyko]

Pls take a look in the log - https://dev.kopeyko.ru/tmp/telegram-v3.2.5.debug20211119.output

I see input device re-detection at line 87810 and no scroll wheel events logged since then. I don't know when it happened though since the log has no timestamps.

How I can enable timestamps?

[ilya-fedin]

looks like QT_MESSAGE_PATTERN="[%{time}] %{if-category}%{category}: %{endif}%{message}"

[AndreyKopeyko]

Pls take a look in the log - https://dev.kopeyko.ru/tmp/telegram-v3.2.5.debug20211119.output

I see input device re-detection at line 87810 and no scroll wheel events logged since then. I don't know when it happened though since the log has no timestamps.

OK, tomorrow morning you'll have the log with a timestamps and with a scroll freeze, both of them.

20211119T013539: qt.qpa.xcb: Has MIT-SHM : true
20211119T013539: qt.qpa.xcb: Has MIT-SHM FD : true
20211119T013539: qt.qpa.xcb: Using XInput version 2.2
20211119T013539: qt.qpa.screen: EDID data for output "eDP-1": identifier 'LP140WF6-SPB1', manufacturer 'LGD',model '', serial '', physical size: 310.00x170.00
20211119T013539: qt.qpa.screen: Output DP-1 is not connected
20211119T013539: qt.qpa.screen: Output HDMI-1 is not connected
20211119T013539: qt.qpa.screen: Output DP-2 is not connected
20211119T013539: qt.qpa.screen: Output HDMI-2 is not connected
20211119T013539: qt.qpa.screen: Output DP-2-1 is not connected
20211119T013539: qt.qpa.screen: Output DP-2-2 is not connected
20211119T013539: qt.qpa.screen: Output DP-2-3 is not connected
20211119T013539: qt.qpa.screen: adding QXcbScreen(0x7f3a05cbf540, name="eDP-1", geometry=1920x1080+0+0, availableGeometry=1864x1053+56+27, devicePixelRatio=1.0, logicalDpi=std::pair(96.0,96.0), physicalSize=309.0x174.0mm, screenNumber=0, virtualSize=1920x1080 (1920.0x1080.0mm), orientation=Qt::LandscapeOrientation, depth=24, refreshRate=60.0, root=7ad, windowManagerName="GNOME Shell") (Primary: true )
20211119T013539: qt.qpa.screen: primary output is "eDP-1"

[AndreyKopeyko]

looks like QT_MESSAGE_PATTERN="[%{time}] %{if-category}%{category}: %{endif}%{message}"

Right, this is better. You'll get it.

[thenetengineer]

Same issue on Ubuntu 20.04.3 LTS - in this case it's a workstation that is on 24/7, I have rebooted, updated and still have the same issue.

[ilya-fedin]

OK, tomorrow morning you'll have the log with a timestamps and with a scroll freeze, both of them.

I hope you understand even if I would have it, I won't be able to fix this

[AndreyKopeyko]

Voila! 7 minutes of sleep (in suspend) was enough for wheel scroll to freeze:

kaa@MRGnb2:~/tmp$ grep -B2 '19T01:53' telegram-v3.2.5.debug$(date +%Y%m%d).output |head -5
[2021-11-19T01:46:19] qt.qpa.events: Event | XCB_PROPERTY_NOTIFY(28) | sequence: 4726
[2021-11-19T01:46:19] qt.qpa.events: Event | XCB_PROPERTY_NOTIFY(28) | sequence: 4726
[2021-11-19T01:53:13] qt.text.font.match: Cache hit level 1
[2021-11-19T01:53:13] qt.text.font.match: Cache hit level 1
[2021-11-19T01:53:13] qt.qpa.events: Event | XInput Event(XCB_INPUT_PROPERTY) | sequence: 7837
kaa@MRGnb2:~/tmp$ 

See full log at https://dev.kopeyko.ru/tmp/telegram-v3.2.5.debug20211119.output2

[ilya-fedin]

@AndreyKopeyko the new log doesn't have any scroll events, at all

[AndreyKopeyko]

@AndreyKopeyko the new log doesn't have any scroll events, at all

Interesting... The command I run was

QT_LOGGING_RULES='*.debug=true' QT_MESSAGE_PATTERN="[%{time}] %{if-category}%{category}: %{endif}%{message}" telegram 2>&1 |tee telegram-v3.2.5.debug$(date +%Y%m%d).output2

How can I check quickly it does contains?

[ilya-fedin]

i just look for scroll wheel

[AndreyKopeyko]

Now it have "scroll wheel" events but not after 03:02 (notebook was suspended from 03:02 till 03:13)

https://dev.kopeyko.ru/tmp/telegram-v3.2.5.debug20211119.output3

[ilya-fedin]

yeah, it has

[AMV007]

Steps to reproduce check scroll working - ok go to suspend resume from suspend mouse scroll not working Expected behaviour scroll working

Actual behaviour scroll not working

Operating system Ubutnu 20

Version of Telegram Desktop 3.2.4

Installation source Static binary from official website

[AndreyKopeyko]

@ilya-fedin FYI - scrolling via 2-finger gesture on touchpad continues to work fine after wheel scroll fails. Do you need a Qt debug log with those events?

[ilya-fedin]

I don't need any logs, I can't fix this issue since it's not at app level

[AndreyKopeyko]

No, you can fix it - just downgrade Qt version used to the working one. The problem will be solved.

[ilya-fedin]

Well, the problem doesn't seem to be so urgent for such actions

[ilya-fedin]

There was a similar issue even before Qt upgrade, #3859. It was existing a big amount of tdesktop lifetime and was closed just because people ignored requests for more information, so maybe they never stopped experiencing the bug, just were so lazy to provide information. So it's something people can live with for years, as the previous experience shows.

[AndreyKopeyko]

Well, the problem doesn't seem to be so urgent for such actions

This is extremely wrong decision. Maybe it is not urgent for you - but it is important for me and a lot of other people who had faced that wheel scroll issue.

[AndreyKopeyko]

There was a similar issue even before Qt upgrade, #3859.

I didn't faced that bug, and you definitely can't blame me for not providing debug information.

So, this note must be considered irrelevant to the issue we are discussing now.

[ilya-fedin]

but it is important for me and a lot of other people

That 'a lot of people' can be a small fraction of userbase, still. There's a lot of issues where people write 'how can't you fix so important bug for years???', the answer is it's not really an important bug. Yeah, for someone it's an important bug in their personal view, but looking more broadly it becomes clear that this is not so important bug for most people, so it has a little priority.

[ilya-fedin]

and you definitely can't blame me for not providing debug information.

No one is blaming you, it's a historical background

So, this note must be considered irrelevant to the issue we are discussing now.

It's relevant as it shows the bug existed earlier, but maybe it was reproducible for smaller group of people or maybe it was existing in older Qt versions and was fixed at some point, but regressed in Qt 6.x

[AndreyKopeyko]

It's relevant as it shows the bug existed eralier, but maybe it wasn't so reproducible

This time you do have the rock-solid way to reproduce the problem, don't you?