Bug 163119 - Keyboard selection of Recent Document fails with Numpad Keys (kf6-only)
Summary: Keyboard selection of Recent Document fails with Numpad Keys (kf6-only)
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
24.8.0.3 release
Hardware: x86-64 (AMD64) Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Qt6
  Show dependency treegraph
 
Reported: 2024-09-24 08:25 UTC by alex
Modified: 2024-12-14 09:02 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description alex 2024-09-24 08:25:41 UTC
Description:
Recent Files can be opened via ALT-menu keyboard shortcuts: ALT-F then U then the number to select, eg 3.
Presently on my openSUSE/KDE Plasma, this numeric selection only works from the top number row, not from the Numpad numbers.
The numpad still works for this on Windows, and also under other window manager (ICEWM checked).

Steps to Reproduce:
1. Open a spreadsheet or document
2. Press Alt+F, U then a numpad key (eg 3) corresponding to a file

Actual Results:
Nothing happens - the flyout menu of recent documents stays open as if nothing were pressed.

Expected Results:
The corresponding file should be opened - as happens on Windows and under ICEWM.



Reproducible: Always


User Profile Reset: Yes

Additional Info:
Version: 24.8.0.3 (X86_64) / LibreOffice Community
Build ID: 480(Build:3)
CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+xcb)
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Calc: threaded

openSUSE Tumbleweed, KDE Plasma 6.15, QT Version 6.7.2
Have also verified:
* Happens on both Wayland and X11 Sessions
* Unaffected by Numlock state
* Keyboard is fine - numpad keys enter into document when typed
Comment 1 Buovjaga 2024-12-11 17:09:47 UTC
Repro, but only with kf6, not even with kf5. Unfortunately the builds in our bibisect repositories do not include kf6 UI (it has been requested that they be rebuilt). Maybe it's a regression, maybe it always behaved like this, we don't know yet.

On my keyboard, I had to have Num Lock active to make the accelerators work.

Arch Linux 64-bit
Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: cc65bec38ca26265ce8ecfd02110c26bcc62b79b
CPU threads: 8; OS: Linux 6.12; UI render: default; VCL: kf6 (cairo+wayland)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: CL threaded
Built on 11 December 2024
Comment 2 Michael Weghorn 2024-12-12 08:42:51 UTC
I can reproduce.

This is a Qt bug, see https://bugreports.qt.io/browse/QTBUG-73390

Suggested fix: https://codereview.qt-project.org/c/qt/qtbase/+/611036
Comment 3 alex 2024-12-12 09:07:57 UTC
(In reply to Michael Weghorn from comment #2)
> I can reproduce.
> 
> This is a Qt bug, see https://bugreports.qt.io/browse/QTBUG-73390
> 
> Suggested fix: https://codereview.qt-project.org/c/qt/qtbase/+/611036

Interesting resolution - thanks for tracking it down!
Amazing that it's 5 years old and has only recently surfaced for me, perhaps with the Plasma 6 shift?
How much chance of it getting fixed by QT 5 years on?
Comment 4 Michael Weghorn 2024-12-12 09:42:34 UTC
(In reply to alex from comment #3)
> Amazing that it's 5 years old and has only recently surfaced for me, perhaps
> with the Plasma 6 shift?

Yes, with Plasma 6, LibreOffice's so-called "kf6 VCL plugin" gets used, while with Plasma 5, it's the kf5 one, and the latter doesn't show the problem (s. comment 1). (It's not immediately clear to me why kf5 doesn't show the problem because QTBUG-73390 was reported for Qt 5 already, which gets used by kf5...)

> How much chance of it getting fixed by QT 5 years on?

In my experience, Qt code reviews usually happen within a reasonable time frame (often within a few days, otherwise weeks). So now that there's a pending fix in Gerrit (Qt's code review system), I'm fairly optimistic it will get fixed upstream somewhat soon. (But you'll only profit from that once a new enough Qt version containing the fix was released and is provided by your Linux distro.)
Comment 5 Michael Weghorn 2024-12-13 17:48:04 UTC
(In reply to Michael Weghorn from comment #4)
> In my experience, Qt code reviews usually happen within a reasonable time
> frame (often within a few days, otherwise weeks). So now that there's a
> pending fix in Gerrit (Qt's code review system), I'm fairly optimistic it
> will get fixed upstream somewhat soon. (But you'll only profit from that
> once a new enough Qt version containing the fix was released and is provided
> by your Linux distro.)

FYI: The change for the current development version (to become Qt 6.10 one day) has been approved and merged now, backports for 6.9 and 6.8 should follow soon, once the CI runs have succeeded.
Comment 6 Buovjaga 2024-12-14 09:02:35 UTC
(In reply to Michael Weghorn from comment #5)
> (In reply to Michael Weghorn from comment #4)
> > In my experience, Qt code reviews usually happen within a reasonable time
> > frame (often within a few days, otherwise weeks). So now that there's a
> > pending fix in Gerrit (Qt's code review system), I'm fairly optimistic it
> > will get fixed upstream somewhat soon. (But you'll only profit from that
> > once a new enough Qt version containing the fix was released and is provided
> > by your Linux distro.)
> 
> FYI: The change for the current development version (to become Qt 6.10 one
> day) has been approved and merged now, backports for 6.9 and 6.8 should
> follow soon, once the CI runs have succeeded.

Thanks, Michael. We would be in a much worse place without your dedication.