GNOME Bugzilla – Bug 772106
Regressions in the context menu after the switch to GAction
Last modified: 2017-11-22 22:56:09 UTC
We have two different ways of disabling items in the context menu. When the action belongs to that context menu, for example cut/copy/paste on editable content, we make the actions not available insensitive. But when the action is doesn't really belong to the context menu, for example copy option when there's a link selected, we hide the option to make the context menu less cluttered. Now both options seem to be broken. To reproduce, select text on a link an right click over the link, you should see the copy option, then clear the selection an open the context menu again, the copy option shouldn't be there anymore, however it's there and enabled. I'm sure there are more cases broken. I'm afraid this is very difficult to achieve with the GMenu, there's a hidden-when GMenuItem attribute that allows you to hide options when the action is disabled or not present. Maybe we need to delay the context menu until we have all the information available and not include options we don't want to show. We have just switched and I'm already missing GtkAction.
(In reply to Carlos Garcia Campos from comment #0) > Maybe we need to delay > the context menu until we have all the information available and not include > options we don't want to show. I want to do this anyway, because it's the only way to fix bug #765145.
Maybe not the most serious bug, but I want to use blocker status to help track priority issues for 3.24.
I think the only problematic menu item is copy, right? I'm going to attach a patch that fixes this in bug #765145. I had to add new WebKitWebEditor API so that I could check the availability of the editing commands in the web process, then I send it to the UI process via context menu user data. Let me know what you think in that bug.
(In reply to Michael Catanzaro from comment #3) > I think the only problematic menu item is copy, right? > > I'm going to attach a patch that fixes this in bug #765145. I had to add new > WebKitWebEditor API so that I could check the availability of the editing > commands in the web process, then I send it to the UI process via context > menu user data. Let me know what you think in that bug. (Stalled since it depends on WebKit API that we decided not to add.)
*** Bug 784437 has been marked as a duplicate of this bug. ***
Created attachment 360500 [details] [review] window: Check context menu item sensitivity using editor state This allows us to get the context menu right without flickering. Notably, we can now hide the copy context menu item once again, without flickering, when it is not available.
This is fixed in master now.