Combine Stop and Refresh in context menu

[Danielle Foré]

Stop and Refresh should appear and disappear in the context menu as appropriate, as if they are two sides of the same coin, not two separate entries.

[Cassidy James Blaede (cassidyjames)]

Yeah, this is how the toolbar button works after all.

[gue5t gue5t (gue5t)]

This is unfortunately pretty far from bitesize as I can see it, due to the way it would need to be implemented:

The first, less problematic, detail is that webkit automatically adds back, forward, stop, refresh, and inspect items to the right-click menu. These would need to be removed and replaced with midori's widget for stop/refresh. I think this shouldn't be a big deal since the code already has conditionals where this could be done and it's clear how to proceed.

The real issue is that the entries in the popup menu are not proxies for GtkActions like the menuitems in toolbars are. This means that they do not automatically reflect whether a given action, such as stopping or refreshing, is possible by being insensitive. This means that if the icon, label, or visibility of an action changes (as in the case of the ReloadStop action or the page state otherwise changes with the menu open), sokoke_action_create_popup_menu_item will have to connect a listener specifically for each possible kind of change to the action's state. On top of this, there is no way to change the mnemonic (a label with a letter underlined that acts as a local hotkey) for an existing menuitem, which is necessary to e.g. change "_Reload" to "_Stop". This means we'd have to manage the label widget ourselves and try to match GTK's behavior. This all implies significant additional complexity and isn't an ideal solution in my opinion.

GTK does provide a way to create menu items for actions, and ideally we could just use these. The problem is that they include hotkey descriptions, which makes the menus wider and is unexpected and undesirable for popup menu items because they are not accessed through hotkeys (only mnemonics, keyboard navigation, or the most common case of a click). There is no direct API in GTK to access the widget containing hotkey descriptions, so it can't merely be hidden in a way that can be guaranteed to work with future GTK versions.

So we have a couple options and both are pretty unsatisfactory. The latter of the two seems much shorter, but what we gain in avoiding complexity we lose in depending on GTK having a specific widget tree inside the menuitem proxies it creates. If that's acceptable, I can probably come up with a patch.

[Cris Dywan (kalikiana)]

Bug 1205064 will probably allow solving this.