components/ContextMenu interfering with gameplay

[Mehuge]

edited for correction changed panning to turning, right click is used to turn your character, left click is used to pan camera.

I hope you don't mind logging this as an issue, but it's a fairly annoying bug, and the solution to it goes beyond I think what the UI can do, or the ContextMenu implementation needs a bit of a re-think.

The Issue

When playing the game, one thing one does is right click somewhere in the game client and move the mouse to turn your character. This is done often in the heat of combat, so right click turn should work pretty much anywhere in the client, certainly anywhere within the main portion of the screen (the peripheries could be an exception).

However, the right click context menu on the unit frames (and Warband UI) is interfering with this for the following reasons:

1. I steals the right click that happens on the unit frame from the game, so if the attempt to turn happened to be while the mouse was over the unit frame, the turn would not work as expected.

2. I places an element, invisible (0.01 opacity) over the full screen which then steals the next right click or left click (which could have been intended to target a player) from the game.

Both these issues make the game seem unresponsive, and it is undesirable IMO.

Possible solutions

Don't use right click for interacting with the UI. Left clicking something is generally always targeted, if you want to target a player, you click the player. If you want to target an UI element you click the UI element.

Right clicking, because of its use for turning, isn't targeted, its done wherever the mouse happens to be, so the UI should never steal the right click from the game client except perhaps near the edge of the screen where it would be unlikely to be intended for the client.

If we are to keep right click for context menus, then there should be some kind of API that allows the UI to pass the event on to the game client.

This would need to be used in two places (for the ContextMenu implementation). In the right click event handler (the handleContextMenu methods, and in the onMouseDown and onKeyDown handlers of the ContextMenu itself. Something like

client.ProcessAsClientEvent(event)

This would mean two things. Right click + drag (turn) on a unit frame would open the context menu but it would also be processed by the client, which if the user is turning rather than right clicking, means the turn works as expected (with a context menu as a side effect), if they are right clicking, the context menu appears as expected and as the user isn't turning no turn occurs.

If we switch to left click for the context menu, then we still need a way to tell the client to pass right click through to the client, perhaps a hud.ui settings handlesRightClick: false.

Another option might be to add intelligence to the logic that decides if the UI or the client gets the right click by only sending right click events to the UI if it is genuinely a right click event, and not a right mouse drag event.

I have a PR I am about to submit that doesn't solve this problem but does at least lessen its occurrence (by not showing empty context menus) and its impact (by only stealing 2 right clicks not all right clicks until click in unit frame again)

[Mehuge]

Another option might be to have the client decide on mouse down if the events should be passed to the UI based on opacity. So if the mouse down is over opacity 0, that event and subsequent events while the mouse is down, and the terminating mouse up event are not passed to the client.

Still doesn't solve the genuine detection of a right click on health bar that the user may not have intended as a right click to get context menu, but was really a failed or aborted attempt at turning.