Created attachment 163848 [details] bibisect-linux-64-7.0, tail of terminal output I first noticed this in a local build of commit 7b443b2c (2020-07-22) on debian-buster. The bibisect result is from bibisect-linux-64-7.0 on the same system. Note that I see the problem only with SAL_USE_VCPLUGIN=gtk3. As the summary states, not all accelerator keys on the tab are afflicted. In the versions where I have observed "<alt>+F" to fail, "<alt>+T" is also ineffective. However, I have never seen a failure of "<alt>+H" or "<alt>+W". The STR use Writer, but I also see the problem in Calc in my (more recent) local build. I have not tried other LibreOffice applications. STR (1) From command line, start Writer using new user profile. Perhaps: userdir=/tmp/bug_20200729a_user rm -rf $userdir ; \ SAL_USE_VCLPLUGIN=gtk3 sof -env:UserInstallation=file://$userdir \ --writer Program displays Writer document "Untitled 1". (2) Menu options Format > Page ("<alt>+O P"). Program presents dialog "Page Style: Default Page Style" tab Organizer. (3) Click on tab Page. (I think "<alt>+<PgDn>" *should* do this, but it often does not. That is a problem for another day.) Program presents dialog Page. Observe that control "Paper Format" > Format has focus, as indicated by a fine dotted border on the value; the value is "A4"; the value of "Text direction" is "Left-to-right (horizontal)". (4) Type "<alt>+T". good : focus moves to control "Text direction" or to control "Paper tray". bad : focus stays on control "Paper Format" > Format. (5) Click on contol "Text direction". (6) Type "<esc>". (7) Type "<alt>+F". good : focus moves to control "Paper Format" > Format bad : focus stays on control "Text direction". (8) Type "L" good : Format is Letter bad : "Text direction" is "Left-to-right (vertical)" The bibisect shows: commit s-h date good 6999637e de1dadd5 2020-04-16 18:18:29 bad 236b1ede bc0e0f63 2020-04-16 18:28:24 The commit message for bc0e0f63 starts: commit bc0e0f633b05c4f91b6695488fc9e5c127507ba5 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Thu Apr 9 11:41:00 2020 +0100 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Thu Apr 16 20:28:24 2020 +0200 tdf#131120 use a replacement for GtkComboBox I am assigning priority trivial because (*) the problem is immediately visible in the dialog, (*) the workaround is obvious, and (*) I was positively looking for trouble when I found this. I am assigning keywords bibisected, bisected, regression.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/36f5265b038b610c61ebc459465c5c58b1d9dc28 tdf#135368 change the mnemonic to point to our combobox replacement It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
fixed in master, backport to 7-0 in gerrit
I see the problem fixed in a local build of commit c84764e0 on debian-buster. Thank you, Caolán. I am setting status VERIFIED FIXED.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/c9221f29f323d0de74f492895b00b4cb86476d6d tdf#135368 change the mnemonic to point to our combobox replacement It will be available in 7.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.