[v3] --default-contextmenu: show is ignored when --custom-contextmenu is set on the same element

[RALIST]

Description

The documentation for context menus shows that --custom-contextmenu and --default-contextmenu can be combined on the same element:

<!-- From docs/src/content/docs/features/menus/context.mdx -->
<textarea
    style="--custom-contextmenu: text-menu; --default-contextmenu: show"
    placeholder="Type here, then right-click...">
</textarea>

The expected behavior is that the custom Go-side menu appears and the browser's default context menu is also shown (or appended).

However, the runtime implementation in v3/internal/runtime/desktop/@wailsio/runtime/src/contextmenu.ts ignores --default-contextmenu entirely when --custom-contextmenu is present:

if (customContextMenu) {
    event.preventDefault();        // ← blocks native menu unconditionally
    openContextMenu(customContextMenu, ...);
}
else {
    processDefaultContextMenu(event, target);  // ← only reached when NO custom menu
}

Since event.preventDefault() is called before checking --default-contextmenu, setting --default-contextmenu: show has no effect when --custom-contextmenu is also defined.

To Reproduce

1. Create an element with both CSS variables:

   <textarea style="--custom-contextmenu: my-menu; --default-contextmenu: show"></textarea>

2. Register my-menu as a context menu in Go
3. Right-click on the textarea
4. Only the custom menu appears; the browser's native context menu (cut/copy/paste) is never shown

Expected behaviour

When --default-contextmenu: show is set alongside --custom-contextmenu, the native browser context menu should also be shown (either merged, appended, or shown sequentially). The documentation example implies this combination is supported.

Suggested fix

After opening the custom context menu, check --default-contextmenu on the same element. If it's show, do not call event.preventDefault() (or call it only after confirming the default menu should be suppressed).

Screenshots

No response

System Details

Wails v3 alpha
Platform: all (runtime-level JS issue)

[leaanthony]

Showing a custom and default context menu together doesn't make much sense. I think they're mutually exclusive?

[RALIST]

Yeah, probably.
My use case:
I tried to "combine" and reuse built-in textarea menu (spellchecker and grammar, dictionary, text transformations) with my custom menu options.
Something like this:

Plus app specific options - "Extract to new document", etc.
So with custom menu you have to re-implement other built-in features provided by OS and sometimes it can be tricky.

Anyway, documentation is not correct atm.

[leaanthony]

Thanks for the use case — that makes sense. The docs are definitely misleading here. The two CSS variables are mutually exclusive in the current implementation. Supporting native OS text services alongside custom menus would require a different approach (e.g. building the native text actions into the custom menu). I'll update the docs to clarify this. PRs welcome if anyone wants to tackle the native text service integration.