feat: support disabled entries in popup menu

[Skaiir]

Related to camunda/camunda-modeler#5109

Proposed Changes

In the context of AO, one of the things we want to be able to do is display disabled connectors for future versions. The first step to this is this here extension of the popup menu allowing disabled entries.

PR contains:

• support for disabled list entries, which mostly just set some styles and swallow actions from enter and click (although we could also just trust the users not to set the action, but generally I don't think we should allow a disabled state with an action).
• (optional) extension of support for disabled header entries, there actually was already some support as a disabled class was passed to the headers, it however wasn't reflected in the types and was generally very barebones, I'm happy to exclude this one out of the current scope as I do not need it for my use case.
• fixing the popup test suites, those 60~ tests were responsible for half the run time of the 2000 tests due to 500ms wait times for events to go through, I managed to get rid of these at least locally, let's see the CI :D

Styling needs some advice from @YanaSegal, I can't go with this super low contrast approach but anything else seems to be too much for the light disabled look.

I've treated the header entries fundamentally different from the list entries. Header entries are only actions, so they become completely un-interactive spans if they are disabled. This already looked like the behavior we were going for if no action was supplied, so I think it makes sense, this can be changed, or again we can drop this part of the PR if this is time sensitive.

List items still need to allow for keyboard based navigation, so they can still be list selected / navigated, just not triggered via enter and mouse clicks. On that note the naming is a bit confusing here so to clarify for review context: "selected" means fake focused / highlighted, and "onSelect" is a trigger/click/enter.

Screencast.from.2025-09-18.23-49-16.webm

Can't seem to get my cursor to record, but hovering gives us a not allowed cursor.

To try it out, you can use bpmn-js-create-append-anything, get this PR as the dependencies (bpmn-js styles will have to be overwritten manually as diagram-js styles aren't used directly, or you can change the style loading to take it directly from djs), and then in CreateMenuProvider you can set disabled: Math.random() < 0.5, under label: label && this._translate(label),

Checklist

To ensure you provided everything we need to look at your PR:

• Brief textual description of the changes present
• Visual demo attached
• Steps to try out present, i.e. using the @bpmn-io/sr tool
• Related issue linked via Closes {LINK_TO_ISSUE} or Related to {LINK_TO_ISSUE}

[Skaiir]

@barmac Hey Maciej, yup I'll need some support here, this is the basic disabled entries support, we'll also need to merge an element template PR later to support getting disabled entries from the element template registry and finally an create-append-anything PR to bring it all together.

[Skaiir]

Man it's a different life when CI doesn't take 30 minutes to execute, definitely less concerned about strategically sending in commits :D

[barmac]

Hmm CI became brittle now. I experience timeout issues on my machine now too.

[barmac]

Hmm CI became brittle now. I experience timeout issues on my machine now too.

I can reproduce it on main and also before your changes (v15.3.0).

[Skaiir]

I can reproduce it on main and also before your changes (v15.3.0).

Was gonna say, if we look at the commit history these errors are present even a few months back.

[barmac]

Regarding the contrast, we can go with opacity as low as 0.6 if we keep the default font color. Contrast is then above 4.5.

[Skaiir]

How does it look with the hover state?

[barmac]

[barmac]

Right, with hover the contrast is super low.

[Skaiir]

Right, with hover the contrast is super low.

There are styles to make it lighter normally, not sure why it's so dark.

[barmac]

I just noticed that you also changed the hover background style which was not applied in my local build. Maybe it's good enough.

[Skaiir]

Good contrast without hover and slightly below with, I think it's okay. If we make it any darker it becomes very unclear that this is disabled. Until they patch human vision I don't think we have a much better approach aside from completely changing the styles.

[barmac]

No opacity changes, slightly lighter color which meets contrast requirements:

[barmac]

I think it looks good enough now. I'll merge it and release it. Thanks!