A MenuItemControl silently ignored WithClass by rbuergi · Pull Request #1045 · Systemorph/MeshWeaver

rbuergi · 2026-08-09T20:39:25Z

MenuItemView never rendered the control's Class on any of its buttons, so WithClass on a MenuItemControl did nothing at all — no error, no warning, just a button that kept the default appearance while the caller believed it had styled it. That is the shape of bug this codebase treats as serious: a call that looks applied and is silently discarded.

How it surfaced

A plugin cover's install step became a split button (MenuItemControl with a click action and child items) and instantly lost the cover's cta-pill geometry and HeroCta palette that every plain button beside it still had — so the row restyled itself the moment something was installed, and only in that state.

The class has to be on the button itself, because the rule is:

fluent-button.cta-pill::part(control) { … }

Putting it on the wrapper div cannot match, so there was no workaround available to the caller.

The fix

Class now reaches the FluentButton in all four shapes the view renders — icon-only, split primary + chevron, expand-only, and the plain in-menu entry — matching what ButtonView has always done.

Style already worked and is unchanged: it lands on the wrapper, and CSS custom properties inherit through the shadow boundary from there, which is how the palette variables reach ::part(control) once the rule applies.

Release build clean with -warnaserror.

🤖 Generated with Claude Code

MenuItemView never rendered the control's Class on any of its buttons, so WithClass on a MenuItemControl did nothing at all — no error, no warning, just a button that kept the default appearance while the caller believed it had styled it. That is the shape of bug this codebase treats as serious: a call that looks applied and is discarded. It surfaced on a plugin cover, where the install step became a split button and instantly lost the cover's `cta-pill` geometry and HeroCta palette that every plain button beside it still had — so a row restyled itself the moment something was installed. The class must be on the button itself, because the rule is `fluent-button.cta-pill::part(control)`; putting it on the wrapper cannot match. Class now reaches the FluentButton in all four shapes the view renders (icon-only, split primary + chevron, expand-only, and the plain in-menu entry), matching what ButtonView has always done. Style already worked: it lands on the wrapper and CSS custom properties inherit through the shadow boundary from there. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Copilot

Pull request overview

Fixes a silent styling bug in the Blazor UI where MenuItemControl.WithClass(...) had no effect because MenuItemView never passed the bound Class through to its rendered FluentButton elements. Adds a corresponding “What’s New” entry documenting the user-visible behavior change.

Changes:

Render the control’s Class on FluentButton across all MenuItemView render shapes (icon-only, split button, expand-only, and plain menu entry).
Add a What’s New page describing the dropdown-button styling fix.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/MeshWeaver.Blazor/Components/MenuItemView.razor	Passes `Class` through to the underlying `FluentButton` so `WithClass(...)` actually affects styling in every menu-item shape.
src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-09-menu-buttons-keep-their-styling.md	Documents the fix in the What’s New feed.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

github-actions · 2026-08-09T20:54:37Z