Bug 424378 - Values of date picker runs out of control for scheduled payments and transactions
Summary: Values of date picker runs out of control for scheduled payments and transact...
Status: RESOLVED FIXED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: 5.1.0
Platform: Arch Linux Linux
: NOR minor
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
: 403335 430630 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-07-18 17:14 UTC by Musikolo
Modified: 2020-12-20 22:03 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 5.1.1
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Musikolo 2020-07-18 17:14:34 UTC
SUMMARY
When enter a scheduled payment and just do one single click on the up or down arrow of date picker, the day portion of the date runs up or down out of control.

STEPS TO REPRODUCE (PATH A)
1. Go to "Home" on the left panel.
2. In the "Payments" area, click on the "Enter schedule" payment button of an existing scheduled payment.
3. Directly click on the up or down arrow button of the date picker to increase or decrease the existing date and wait for a couple of seconds.

STEPS TO REPRODUCE (PATH B)
1. Go to "Schedule payments" on the left panel.
2. Right-click on any existing transaction and click on the "Edit scheduled transaction" option.
3. Directly click on the up or down arrow button of the date picker to increase or decrease the existing date and wait for a couple of seconds.

OBSERVED RESULT
The day component of the date picker runs up out of control until it reaches the end of the month. Conversely, if you clicked on the down arrow button, the day goes down out of control until it reaches the beginning of the month.

EXPECTED RESULT
It should go up or down one single day per click, unless you hold your click (long-press) on either the up or down arrow button.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 
KDE Plasma Version: 5.19.3
KDE Frameworks Version: 5.72.0
Qt Version: 5.15.0

ADDITIONAL INFORMATION
Kernel version: 5.7.8-arch1-1
Comment 1 Jack 2020-07-18 17:50:36 UTC
Have you confirmed this is specific to the date part of the date picker?  Have you tried it on the year or month?  Have you tried using any other date picker in another app?  (Just trying to be sure if this is specific to one widget or more general.)
Comment 2 Jack 2020-07-18 22:23:18 UTC
I also wonder if you have check mouse click behavior in any scroll-bar, just to be sure it's not an issue with your mouse buttons sticking.  Not likely, but easy enough to rule out.
Comment 3 Thomas Baumgart 2020-07-19 09:07:49 UTC
This is weird: the date picker object is used in other areas (e.g. transaction editor) where this problem does not show up. I analyzed it, and the problem is that the very first MouseReleaseButton event on the date picker after object creation is not reaching the object under unknown circumstances. This is not always, but the scenario you have reported shows it. I have no idea about the root cause, though.

So it's not related to flaky hardware or the date picker in general.
Comment 4 Thomas Baumgart 2020-07-19 09:23:32 UTC
Git commit fae59666c95c22ac68df3f347ba14c5e41a47f34 by Thomas Baumgart.
Committed on 19/07/2020 at 09:21.
Pushed by tbaumgart into branch '5.1'.

Add missing release event in very specific case

The date picker object is used in other areas of KMyMoney (e.g.
transaction editor) where this problem does not show up. I analyzed it,
and the problem is, that the very first MouseReleaseButton event on the
date picker after object creation is not reaching the object under
unknown circumstances in the enter schedule dialog. This is not always,
but the scenario reported in the bug entry shows it. I have no idea
about the root cause, though.

Detecting the specific scenario and sending a mouse release button event
based on the data of the press event solves the problem. Drawback:
pressing the mouse long in that scenario now has no effect. It needs a
second press to get the number increasing while the mouse button is
pressed.
FIXED-IN: 5.1.1

M  +26   -0    kmymoney/widgets/kmymoneydateinput.cpp
M  +5    -0    kmymoney/widgets/kmymoneydateinput.h

https://invent.kde.org/office/kmymoney/commit/fae59666c95c22ac68df3f347ba14c5e41a47f34
Comment 5 Thomas Baumgart 2020-07-19 13:11:28 UTC
Git commit 2731fc0e2237d295e80d54e026c44b10110a287a by Thomas Baumgart.
Committed on 19/07/2020 at 11:05.
Pushed by tbaumgart into branch 'master'.

Add missing release event in very specific case

The date picker object is used in other areas of KMyMoney (e.g.
transaction editor) where this problem does not show up. I analyzed it,
and the problem is, that the very first MouseReleaseButton event on the
date picker after object creation is not reaching the object under
unknown circumstances in the enter schedule dialog. This is not always,
but the scenario reported in the bug entry shows it. I have no idea
about the root cause, though.

Detecting the specific scenario and sending a mouse release button event
based on the data of the press event solves the problem. Drawback:
pressing the mouse long in that scenario now has no effect. It needs a
second press to get the number increasing while the mouse button is
pressed.

(cherry picked from commit fae59666c95c22ac68df3f347ba14c5e41a47f34)

M  +26   -0    kmymoney/widgets/kmymoneydateinput.cpp
M  +5    -0    kmymoney/widgets/kmymoneydateinput.h

https://invent.kde.org/office/kmymoney/commit/2731fc0e2237d295e80d54e026c44b10110a287a
Comment 6 Ian Neal 2020-08-11 09:49:42 UTC
*** Bug 403335 has been marked as a duplicate of this bug. ***
Comment 7 Thomas Baumgart 2020-12-20 22:03:00 UTC
*** Bug 430630 has been marked as a duplicate of this bug. ***