Preview mode & automatic components borders toggling

button would already be deactivated by the time Preview's run would be executed no matter what, is that correct ?

oh yeah, right 🤦‍♂

From your reply on the linked issue, I understand this behaviour is intended, so maybe the solution is simply to separate the two buttons contexts as you suggested ?

Ok, it might actually work... being in a different context it will not be stopped by other buttons, and you can also stop relying on buttons at all (as you said I can place it in another panel) and check instead the state of the command by using Commands.getActive API

if ('sw-visibility' in editor.Commands.getActive()) {
	// sw-visibility is active
}

Thanks @mcottret for all the references, really well-written issue :)

When the preview & the sw-visibility buttons are in the same panel, the behaviour introduced by #2589 breaks, this seems to come from the ButtonView's active change listener , which deactivates all active buttons in the panel. So if the preview is activated, it deactivates the sw-visibility button before running the command, which later breaks its active check.

I think, in this case, we should actually create a variable flag by checking if the sw-visibility is active, before doing this: https://github.com/artf/grapesjs/blob/85b7b82103e12fb01a3700b1002a57a7b60ccaf1/src/commands/view/Preview.js#L20 Then on stop, we check the variable stored on start (instead of the button)

Thanks for the reply @artf !

I'm sorry but I'm not sure how to make this work, from what I understand the active change listener gets executed before the Preview's run, so the sw-visibility button would already be deactivated by the time Preview's run would be executed no matter what, is that correct ?

From your reply on the linked issue, I understand this behaviour is intended, so maybe the solution is simply to separate the two buttons contexts as you suggested ?

What do you think about point 1. & my proposed solution ? I already added the safeguard in case the sw-visibility button would have been removed in this PR, but it does not handle a case where the sw-visibility button would be present in another / custom panel (with an id not equal to 'options').