Steps: 1) Start gtk3 build of writer 2) press f6 twice to access menu bar (bug 101879) 3) notice that the file menu header isnt highlighted 4) press down doesnt open the file menu, so press left or right to move to a different menu 5) move to the insert menu and notice the menu header isnt highlighted and the menu isnt aligned with the menu header 6) move the mouse to the menu and notice the gtk3 menu will appear and the gtk2 menu wont disappear Tested with own build of 5.3 master.
Can't reproduce under Fedora 24. I don't see anything unusual with the menu, and there is only gtk3 one.
Maybe a screenshot would help to explain. I especially don't understand the comment about "gtk2 menu wont disappear" and "gtk3 menu will appear". Its supposed to be a fairly stock gtk3 menubar widget and set of menus, by which I mean we have fairly limited direct interaction with it.
Created attachment 127195 [details] screencast hopefully this will explain it all.
Yikes, well that looks utterly vile. So the first "gtk2" menu be a vcl menu themed (badly) to look native, and then the other better looking one is the true gtk3 menu. I wonder how that comes about. Is it a self-build or a tinderbox build ? Maybe its some particular version of gtk3 that's falling through some ifdef gap
OK, I reproduced this with the build from git://dev-downloads.libreoffice.org/lo-linux-dbgutil-daily.git as follows: Fedora 23 livecd - reproducible Fedora 24 livecd - not reproducible Xubuntu 16.04 VM - reproducible Xubuntu 16.04 VM + gtk 3.20 from PPA - not reproducible So this happens if the system gtk where LO runs is 3.18, but not if it's 3.20 - even if LO wasn't compiled against 3.20.
I see it by LD_LIBRARY_PATH pointed to a gtk 3.18 library under fedora 24, looks like the keyboard focus wasn't grabbed by the gtk widget so the keypresses go to the vcl menubar which throws up its own menus then.
Using bisect in gtk itself. This began to work in gtk with commit d54f208d2969550c9eb182b2d5f6173021a1ff34 Author: Carlos Garnacho <carlosg@gnome.org> Date: Thu Nov 26 19:54:54 2015 +0100 GtkMenu: Use gdk_seat_grab()
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d45d8ae3c51606eb1d9e63396a0eab13c8742907 Resolves: tdf#101881 gtk3 3.18 menubar doesn't grab keyboard... It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
That does the trick for me with gtk 3.18. Maybe its a mistake in the first place to sort of emulate the "activate the menubar without activating a menu" behaviour. I don't see gnome apps working this way. But for the moment lets keep on this road.
Thanks for the quick fix Caolan. Will test my git build and report back. Is this something worth backporting to 5.2 or 5.1?
https://gerrit.libreoffice.org/#/c/28759/ for 5-2. IIRC the 5-1 series doesn't have the native menubar so its not relevant there.
Tested the git build and it works great. Thanks.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=571c187f0610f59573b5e2285b6bfc9589236532&h=libreoffice-5-2 Resolves: tdf#101881 gtk3 3.18 menubar doesn't grab keyboard... It will be available in 5.2.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I can still reproduce this on libreoffice-5-4 branch or something similar. 1) Close and reopen libreoffice writer. 2) Press F6. 3) Press O (shift O to use the upper case O). 4) Notice the old menu. Close libreoffice writer again. 1) Open libreoffice writer. 2) press F6 3) Press o (lower case o). 4) Notice the new native gtk+ menu.
(In reply to Hussam Al-Tayeb from comment #14) > 1) Close and reopen libreoffice writer. > 2) Press F6. > 3) Press O (shift O to use the upper case O). > 4) Notice the old menu. Thanks Hussam. I can confirm this in master as well. Version: 6.0.0.0.alpha0+ Build ID: dd5868409ae430f9c9ffea18ea7e287a65cfa2ab CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group @Caolan: do you want to fix this issue here or in another bug?
2016-09-11 ... a patch related to this issue ... has been pushed 2017-09-19 ... I can still reproduce this on libreoffice-5-4 branch or something similar There are 12 months between these comments and the bug now newly described is not exactly the same as the originally reported problem, though there are similarities, so reopening is not a recommended procedure after such a gap in time. But I'll fix it anyway under this id. The original problem was that all the menus that appeared on keyboard traversal were both native and emulated menus, the newly described problem is that a particular keystroke causes this to happen, i.e. pressing o gives the native menu and shift+o gives the emulated menu, presumably because the shift+o isn't handled by the native menubar but there's a fallback to the vcl menubar keystroke handler which pops up its own menu in response
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f9a48edc0a4c9144a2091ab782f6a6676bfcf4bf Related: tdf#101881 keys not handled by native menubar sent to vcl one It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #17) > Caolán McNamara committed a patch related to this issue. > It has been pushed to "master": > > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=f9a48edc0a4c9144a2091ab782f6a6676bfcf4bf I tested master and now pressing shift+o doesnt do anything. Version: 6.0.0.0.alpha0+ Build ID: 46fa042b94a0364c09482e8a09f8874119db231c CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group
yes, this is "a good thing"
(In reply to Caolán McNamara from comment #19) > yes, this is "a good thing" well then its inconsistent between gtk2 and gtk3, so would if it is 'a good thing', can we disable it in gtk2 as well?
I don't see that it matters.