Misclick on controls states and history

We had a report on usability with a better separation of Controls to avoid misclick.

The report from November 2025 got at least two advice related to the toolbar buttons:

• "don't put a button deleting the data forever close to the buttons using the data" > that's why we are not activating "clear logs" by default
• "don't shift" buttons position left and right according to the live state > that's why we put State buttons at the start of the end region today

Do not hide Publish / Restore / Revert

OK, I may have a proposal where the state buttons island is never totally hidden.

We can use a "Split button":

A split button is a dual-function menu button that offers a default action as well as the possibility of choosing a different action by selecting from a set of alternatives.

Definition: https://www.nngroup.com/articles/split-buttons/
Example: https://getbootstrap.com/docs/5.3/components/dropdowns/#split-button

Available in Drupal Core as "dropbutton" render element: www.drupal.org/docs/develop/user-interface-standards/dropdown-buttons

Unfortunately not available in Shoelace as far as I know.

The default action is Publish, the secondary actions are "Restore" and "Revert":

It is OK to have a single secondary action:

The split button is never hidden and always take the same horizontal space, whatever the current data state:

• If "Publish" is not available (because not activated in config and/or revision already published), the main button is disabled but the secondary actions are still available:
  
• If "Publish" is available but no secondary actions are available (because not activated in config or because the current state doesn't allow them), the second part of the split button is disabled:
  

It is not shifting other buttons left and right anymore, so we can position it at the end of the end region, just before the "Back" button, because the less "hot" is a button, the further from the center it belongs:

What do you think about this?

There is a dropdown in shoelace but then I think it's a menu, worth to try.

Worth to try, indeed. The most important is to let people know there are actions available or not in the dropdown without clicking on it, just be checking if enabled/disabled state of the dropdown button:

And for History clear?

History clear button would not be such a problem if those 3 conditions are met:

• clear is disabled by default > ✅ already the case, if casual users have the risk if misclick, it will not be because of Display Builder, but because of the site admin which edit the Profile
• button position is not shifting left and right > ✅ it will be better when we the change in StateButtons
• clear action can be undo and/or have a confirmation step > how can we do that?

So I guess, we are not in review anymore :)

Pushed a minor visual fix for color and width, with this fix setup it's harder to test icons only or icon+label option, decided to remove it for now.

OK, I will pull before resuming my ongoing review.

For review removed clear, and dropdown publish.

Before reviewing, just a check:

• "Publish" and "Restore" are always available in the same time, right? When the current revision is not published.
• "Revert" is specific to EntityViewOverride and is not dependent to the published state (except the fact that the display mus have been published at least once, but taht's out of scope of this analysis) so is displayed for all revisions

Horizontal shifting

❌ Because the dropdown is removed instead of disabled when there is no actions, we are missing the goal of not shifting horizontally the toolbar layout when the state change.

Other feedback

Sorry to put this in the table again but the context is evolving: is this the opportunity to merge SaveStatus into StateButtons?

• it will save a plugin to manage, both in codebase and in admin UI config
• the information the 2 islands are related to the same states (saved, published, reverted...) and will more understandable if they are always physically close in the UI
• SaveStatus is always taking the same horizontal space now (it was not the case at the beginning), so it will not mess with our efforts and it doesn't need to be put at the start region

Also, I saw the removal of HtmxEvents::onClear(), does that mean ApiController::clear() may also be removed? If the clear feature move from Display Builder UI to the Drupal Admin UI (i have no opinion about this, just chatting), we may reach the scope of #3577222: Instance history steps settings and ability to disable, using a contrib module like revision_manager, or implementing our own entity operation in /admin/structure/display-builder/instances

A follow up will be with logs island closer to the history feature.

I guess you are exploring something like the pop-up panel triggered from HistoryButtons you told me about? That's interesting.

and current event attachment of saveStatus justify it's own plugin.

OK, convinced :)

Yes the shift is back but not the root fix on misclick as restore/revert are not accessible. It only concern EntityView/Override, I will see to keep it disabled then.

I also see the shift in PageLayout for example, and I guess it is also in ViewDisplay, so it would be great if we success disabling the dropdown instead of removing it when the revision is published.

cool