Hey @Steve-Mcl,
I think we should give @hotNipi the Node-RED award for creativity this week 
Very simple workaround, so I got to love it ...
On the other hand, it is so pitty that we cannot handle this kind of stuff in the dashboard code (so all contributions could benefit from a standard solution). Did some debugging and I was almost close, but no sigar:
-
As soon as an input message arrives, that input message is being stored (with the node id as key) in
replayMessages: -
Immediately afterwards the 'ui-replay-state' event is triggered, and the handler will get the message (for this node id from
replayMessages) and send it to the browser:
So the message really needs to be in
replayMessages, otherwise it will never be send to the browser!
-
But when I deploy my flow, I again arrive in the same event handler. So the same message will be send to the browser here, which is not what I want.
I don't see any way to avoid the ui-replay-state event being triggered, so I tried if I could remove the message from the replayMessages variable. When we call addWidget in our node, and I debug into that function I see that the replayMessages is indeed available in the ui.js:
When I execute (inside the add function) the following in my Chrome debugger console:
delete replayMessages[opt.node.id];
Then the event handler has no message to send to the browser (for the current node id), so no contextmenu appears, so problem solved.
@dceejay: is there any way we can access the replayMessages variable from our node (just before we call addWidget)? Here my Javascript knowledge suddenly ends ...
