Bug 101881 - after using F6 to activate the native gtk3 menubar, the menus opened by keyboard traversal are the vcl menus, not the gtk3 ones
Summary: after using F6 to activate the native gtk3 menubar, the menus opened by keybo...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:5.3.0 target:5.2.3 target:6.0.0
Keywords: accessibility
Depends on:
Blocks: a11y-Linux Main-Menu GTK3
  Show dependency treegraph
 
Reported: 2016-09-03 19:01 UTC by Yousuf Philips (jay)
Modified: 2017-09-25 12:53 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
screencast (7.50 MB, video/webm)
2016-09-07 13:34 UTC, Yousuf Philips (jay)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) 2016-09-03 19:01:41 UTC
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.
Comment 1 Maxim Monastirsky 2016-09-06 22:34:49 UTC
Can't reproduce under Fedora 24. I don't see anything unusual with the menu, and there is only gtk3 one.
Comment 2 Caolán McNamara 2016-09-07 13:08:47 UTC
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.
Comment 3 Yousuf Philips (jay) 2016-09-07 13:34:03 UTC
Created attachment 127195 [details]
screencast

hopefully this will explain it all.
Comment 4 Caolán McNamara 2016-09-07 17:49:23 UTC
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
Comment 5 Maxim Monastirsky 2016-09-07 22:50:33 UTC
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.
Comment 6 Caolán McNamara 2016-09-08 09:20:07 UTC
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.
Comment 7 Caolán McNamara 2016-09-08 15:26:46 UTC
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()
Comment 8 Commit Notification 2016-09-08 21:04:15 UTC
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.
Comment 9 Caolán McNamara 2016-09-08 21:06:18 UTC
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.
Comment 10 Yousuf Philips (jay) 2016-09-08 21:46:58 UTC
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?
Comment 11 Caolán McNamara 2016-09-09 07:05:27 UTC
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.
Comment 12 Yousuf Philips (jay) 2016-09-09 07:24:16 UTC
Tested the git build and it works great. Thanks.
Comment 13 Commit Notification 2016-09-11 08:03:55 UTC
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.
Comment 14 Hussam Al-Tayeb 2017-09-19 12:18:51 UTC
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.
Comment 15 Yousuf Philips (jay) 2017-09-19 17:58:42 UTC
(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?
Comment 16 Caolán McNamara 2017-09-20 10:17:33 UTC
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
Comment 17 Commit Notification 2017-09-20 13:24:45 UTC
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.
Comment 18 Yousuf Philips (jay) 2017-09-22 13:15:30 UTC
(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
Comment 19 Caolán McNamara 2017-09-25 09:49:07 UTC
yes, this is "a good thing"
Comment 20 Yousuf Philips (jay) 2017-09-25 10:46:36 UTC
(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?
Comment 21 Caolán McNamara 2017-09-25 12:53:03 UTC
I don't see that it matters.