STR (1) Assign envvar SAL_USE_VCLPLUGIN=gtk3 and start LibreOffice from the command line. The program displays Start Center. (2) Type <ctrl>+O. Observed : no visible result Expected : file open dialog (3) Type <ctrl>+Q. Observed : no visible result Expected : program should quit I did some of my tests with --safe-mode, and I did not see any difference. Note for comparison: (*) I am using <ctrl>+O and <crtl>+F as examples; some (at least) other control keys are similarly afflicted. (*) With SAL_USE_VCLPLUGIN=gen, then problem is not apparent in Start Center. (*) Calc and Writer display their main windows first with a grey file-open icon in the toolbar. While that icon is grey, these applications also ignore <ctrl>+O and <crtl>+F. After a short interval, the applicationss repaint their control bars with a colored icon for file-open; thereafter control keys work as expected. This behaviour of Calc and Writer is evident with both SAL_USE_VCLPLUGIN=gtk3 and SAL_USE_VCLPLUGIN=gen, but in the latter case the interval with the grey file-open icon is really short. I see this on debian-buster, both in recent versions from the bibisect-linux-64-6.6 repository and local builds. In a local build of commit f22044a4, configured: CCFLAGS=-Wshadow --with-jdk-home=/usr/lib/jvm/default-java --enable-split-debug --enable-gdb-index --enable-ld=gold --enable-option-checking=fatal --enable-dbgutil --enable-debug --without-system-postgresql --without-myspell-dicts --with-extra-buildid --without-doxygen --with-external-tar=/home/terry/lo_hacking/git/src --without-package-format each press or release of a key, even the <ctrl> modifier, seems to provoke the terminal message (rewrapped): warn:vcl:721:721:vcl/source/window/winproc.cxx:856: ImplHandleKey: Keyboard-Input is sent to a frame without focus
Created attachment 156800 [details] bibisect-linux-64-6.5, tail of terminal output Working on debian-buster with the bibisect-linux-64-6.5 repository, I see that the bad bahaviour entered LibreOffice somewhere in the nine commits: commit s-h date -------- -------- ------------------- good 00e616e6 e1c2bb57 2019-12-19 13:20:23 bad 44865672 f22044a4 2019-12-19 18:08:28 Within this range I notice: commit bce3b6af1a71d4586f1e0d4cf56cd794454ea3b1 Author: Caolán McNamara <caolanm@redhat.com> Date: Tue Dec 17 15:32:23 2019 +0000 allow default GtkWindow to handle key events first which, in the case of native GtkWidget children of a LibreOffice window would get the keystrokes to the correct focused widget Change-Id: I0c0864701668f0b6b017517c3065c11322fdc45d Reviewed-on: https://gerrit.libreoffice.org/85308 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> I am adding keywords regression, bibisected.
On pc Debian x86-64 with master sources updated yesterday, I could reproduce this. I noticed this on console: warn:vcl:7943:7943:vcl/source/window/winproc.cxx:855: ImplHandleKey: Keyboard-Input is sent to a frame without focus warn:vcl:7943:7943:vcl/source/window/winproc.cxx:855: ImplHandleKey: Keyboard-Input is sent to a frame without focus warn:vcl:7943:7943:vcl/source/window/winproc.cxx:855: ImplHandleKey: Keyboard-Input is sent to a frame without focus warn:vcl:7943:7943:vcl/source/window/winproc.cxx:855: ImplHandleKey: Keyboard-Input is sent to a frame without focus warn:vcl:7943:7943:vcl/source/window/winproc.cxx:855: ImplHandleKey: Keyboard-Input is sent to a frame without focus warn:vcl:7943:7943:vcl/source/window/winproc.cxx:855: ImplHandleKey: Keyboard-Input is sent to a frame without focus warn:vcl:7943:7943:vcl/source/window/winproc.cxx:855: ImplHandleKey: Keyboard-Input is sent to a frame without focus
I don't see this problem in Fedora 31 with gtk3-3.24 under gnome-shell. What versions and window manager does it appear under ?
Maybe this is the same problem as bug 129634 which appeared at the same time ?
I saw this problem with xfce. I should have thought to say that in my original report. This does sound very much like bug 129634. I am setting status RESOLVED DUPLICATE in anticipation of seeing the problem fixed as soon as I refresh my local build. *** This bug has been marked as a duplicate of bug 129634 ***
On pc Debian x86-64 with master sources updated today, I don't reproduce this anymore: echo $XDG_CURRENT_DESKTOP $GDMSESSION => GNOME lightdm-xsession apt-cache show libgtk-3-0 => 3.24.13-1
I see that this problem is fixed in a local build of commit 92ccf53b running on xfce in the environment of the bug description. However, the problem in bug 129634 persists for me, so I am removing the DUP resolution from this bug and setting bug status RESOLVED FIXED, on the assumption that commit f1604675 <https://git.libreoffice.org/core/commit/f1604675e71c67024887d12bf73ccb86ac05a7a3>, referenced in <https://bugs.documentfoundation.org/show_bug.cgi?id=129634#c5> fixed this bug. I still see the initial delay before Calc or Writer will respond to control keys. I wonder, does this amount to a bug? Advice welcome.
Issue verified in Version: 6.5.0.0.alpha0+ Build ID: 838935758a5ec8e0e68f4df0cf5bfcf737e3f6f2 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded