Exact behavior of 'If msg arrives on input, emulate a button click' for (new) dashboard 2.0 buttons?

As I recall, in the old dashboard, if I sent a message without a 'payload' the given button would not fire. Such that sending... Not generate a click...

msg = {
enabled:false
}

Would disable the button. Of course, this would enable (it again)... Not generate a click...
msg = {
enabled:false
}

But the following would not only enable the button, but generate a click...
msg = {
enabled:false
payload: [Whatever]
}

Is this still the logic?

I am not at my pc, but I believe it should only generate a click if the payload is present and matches one of the on/off values configured in the node. Are you seeing something different?

[Edit, no, that is for a switch of course. What do the docs say?]

Having tested it then it does seem that any message will generate a click event, which is what the docs say. Personally I think that if the message only includes properties such as enabled or ui_update that it should not generate a click, but it could be argued that that would be a breaking change.
I have never used emulate click event, if I want something to have the same action as a click then I just wire it round the button and straight into the following node.

I think it would be worth submitting an issue against the dashboard to see what the response is.

Generated the issue/request Allow disable or enable of control, even when click message pass-thru is enabled? · Issue #2288 · FlowFuse/node-red-dashboard · GitHub

Hope it is accepted!

I think it would be a good idea to edit the title of the issue to make clear that it is related to the button widget.

That is a valid point... updated the issue.

Not sure whether I get the full gist of your intended use, but I have a possible similar scenario where I need a dashboard 2 switch to be visually responsive to an input but not to pass through input msg, or on other times to pass through the input msg, while at all times it is responsive control from the dashboard.

// Passthru ON
msg._block_passthru = false;
return msg;

//Passthru OFF
msg._block_passthru = true;
return msg;

and for the Passthru Filter

// Allow dashboard-originated messages
if (msg._client) {
    return msg;
}

// Block messages where passthru is OFF
if (msg._block_passthru === true) {
    return null;
}

// Allow everything else
return msg;

Hope this helps.

The use case is to normally emulate a button click when a message is passed in, but be able to enable or disable the button without emulating a click.

Of course it depends on the scenario, in my situation I wanted to reset a dashboard 2 switch as a result of a failed outcome from using the switch, but the reset msg should also not pass further along the flow path.
The ability to inactivate the pass thru of the switch would also have been useful for my situation, but the work around of controlling the pass thru outcome was a suitable alternative.