Bug 99857 - gtk3: Several items are missing from a toolbar right click menu
Summary: gtk3: Several items are missing from a toolbar right click menu
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.2.0.0.alpha1
Hardware: All Linux (All)
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:5.2.0
Keywords: regression
Depends on:
Blocks:
 
Reported: 2016-05-15 12:04 UTC by Maxim Monastirsky
Modified: 2016-10-25 19:03 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 Maxim Monastirsky 2016-05-15 12:04:18 UTC
Right click on a toolbar. At least all these are missing: Visible buttons, Customize Toolbar..., Lock Toolbar Position, Close Toolbar.
Comment 1 Caolán McNamara 2016-05-15 20:17:41 UTC
seems to be three empty sections at the end
Comment 2 Caolán McNamara 2016-05-16 08:29:12 UTC
We activate and deactivate the menus on the UpdateAll effort to force vcl to fill the full structure in order to get the full model. This menu has a deactivate handler which empties out the submenus so its incomplete.

Maybe if we try and limit the activate/deactivate to submenus, and leave the toplevel alone assuming that its always "good" then we can squeak by this
Comment 3 Commit Notification 2016-05-16 09:45:05 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=a30e3ea231dd1a355e616fed33eb7c4c4866c12c

Resolves: tdf#99857 missing items from toolbar right click

It will be available in 5.2.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 4 Caolán McNamara 2016-05-16 09:50:39 UTC
Nah, that leads to the sub deactivate arriving before the Select anyway, which still causes trouble.

I don't see the advantage to the "Deactivate" vs just doing the body of that after the Execute has finished. Which is simpler and safer.