this is my proposed patch, to allow isContextMenu to be inserted in either base or item, and then within either the respective action's window or params block

Opinions? I've tested this by exercising every CM I know of in the UI and they all work fine, but would like to hear if anyone has issue with this.

Index: SlimBrowserApplet.lua
===================================================================
--- SlimBrowserApplet.lua	(revision 9424)
+++ SlimBrowserApplet.lua	(working copy)
@@ -1878,8 +1878,12 @@
 			iAction = _safeDeref(item, 'actions', 'preview')
 		end
 
+		--BUG 16697: clean up incongruity of isContextMenu between base and item by allowing it to be
+		--           specified in either the window or params block within the action
 		local isContextMenu = _safeDeref(item, 'actions', actionName, 'params', 'isContextMenu')
 			or _safeDeref(chunk, 'base', 'actions', actionName, 'window', 'isContextMenu')
+			or _safeDeref(item, 'actions', actionName, 'window', 'isContextMenu')
+			or _safeDeref(chunk, 'base', 'actions', actionName, 'params', 'isContextMenu')
 
 		local itemType = _safeDeref(item, 'actions', actionName, 'params', 'type')

while this might fix one inconsistency it introduces another.
actions params/window should always override the base

your patch gives precedence to 

base.window over 
action.window

It needs to be the other way round (and with params having precedence over window).


Why not just leave it as it is?
While it might not be consistent there is a single defined way how to define the context menu in the base vs. how to define the context menu in the action.

Stefan- I don't think that's true. If you look at the patch, it's looking for an isContextMenu flag in

base->actions-><actionName>->window
or
base->actions-><actionName>->params
or
item->actions-><actionName>->window
or
item->actions-><actionName>->params

instead of
base->actions-><actionName>->window
or
item->actions-><actionName>->params

it does not affect handling of base.window

However, I'm fine with just not doing anything. Was trying to clean this up so it had some consistency across base and item, but I can see your point that it's not necessary

Isn't it even more complicated?

Shouldn't 
item->actions-><actionName>   (if available) 
completely override
base->actions-><actionName>

At least later on there is a clear separation of bAction and iAction and only one gets assigned to 'jsonAction'.

So the 'old' isContextMenu code is wrong already.

Of course fixing that is not backwards compatible, but if it helps:
SqueezePad works exactly like that: first the item-action or the base-action is selected, only then I look into params.isContextMenu and window.isContextMenu.

So far noone complained, but my userbase might not be as big as yours ;)

I've opted to do nothing with regards to this. Code stays as it is.

Ok to not do anything. Bug is closed.