Milestone 6: Feature Gap Closure — 54 work items closing ~345 audit gaps

[csharpfritz]

Milestone 6 — Feature Gap Closure

Summary

Closes the highest-impact feature gaps identified in the 53-control audit. This milestone delivers 54 work items across 3 priority tiers, closing an estimated ~345 audit gaps and raising overall project health from ~68% to ~85%.

Branch: milestone6/feature-implementation
Commits: 18 (excluding .ai-team housekeeping)
Files changed: 168 | +5,712 / -1,775 lines
Tests: 1,065 passing (0 failures)

---

P0 — Base Class Fixes (~180 gaps closed)

WI	Change	Impact
WI-01/02/03	AccessKey on BaseWebFormsComponent	~40 gaps across all 53 controls
WI-04/05/06	ToolTip on BaseWebFormsComponent	~35 gaps across all controls
WI-07/08/09	DataBoundComponent<T> inherits BaseStyledComponent	~70 gaps across 5+ data controls
WI-10/11/12	ValidatorDisplay enum + Display on BaseValidator	6 gaps + layout fidelity
WI-13/14	SetFocusOnError on BaseValidator	6 gaps
WI-15/16	Image base class → BaseStyledComponent	11 gaps
WI-17/18	Label base class → BaseStyledComponent	11 gaps

P1 — Individual Control Improvements (~120 gaps closed)

GridView Overhaul

WI	Feature
WI-19/20/21	Paging — AllowPaging, PageSize, PageIndex, PageIndexChanged event, pager row
WI-22/23/24	Sorting — AllowSorting, SortDirection, SortExpression, clickable headers
WI-25/26/27	Row Editing — EditIndex, EditRowStyle, RowEditing/RowUpdating/RowDeleting events

Other Controls

WI	Feature
WI-28/29/30	Calendar: 9 style properties → TableItemStyle sub-components
WI-31/32	Calendar: DayNameFormat/TitleFormat string → enum
WI-33/34/35	FormView: HeaderText, FooterText, EmptyDataText/Template, CssClass
WI-36/37	HyperLink: NavigationUrl → NavigateUrl (with backward compat)
WI-38/39/40	ValidationSummary: HeaderText, ShowSummary, ValidationGroup

Docs, Audit & Integration Tests

WI	Deliverable
WI-41	PasswordRecovery re-audit (0% → 73.7%)
WI-42/43/44	GridView, Calendar, FormView documentation updates
WI-45/46	Playwright integration tests for new GridView + updated sample pages

P2 — Nice-to-Have (~45 gaps closed)

WI	Feature
WI-47	DataTextFormatString on new BaseListControl<T> (all 5 list controls)
WI-48	AppendDataBoundItems on BaseListControl<T>
WI-49	CausesValidation + ValidationGroup on CheckBox, RadioButton, TextBox
WI-50	Menu Orientation enum (Horizontal/Vertical)
WI-51	Label AssociatedControlID (renders <label for> for accessibility)
WI-52	Login/ChangePassword/CreateUserWizard → BaseStyledComponent (~30 gaps)
WI-53	32 bUnit tests for all P2 features
WI-54	Sample pages for DataTextFormatString, Menu Orientation, Label AssociatedControlID

---

Testing

• Unit tests: 1,065 passing (0 failures, 0 skipped)
• Build: 0 errors across library, test, and sample projects
• Integration tests: Playwright tests added for GridView Paging, Sorting, and InlineEditing pages

Breaking Changes

• HyperLink.NavigationUrl renamed to NavigateUrl (old property forwarded via [Obsolete])
• Calendar string-based style properties (e.g., DayStyleCss) marked [Obsolete] in favor of <DayStyle> sub-components
• AppendDataBoundItems defaults to false — data-binding now replaces static items unless AppendDataBoundItems="true" (matches Web Forms behavior)

To fix the problem, the field NameRef should be marked readonly so it cannot be reassigned after object initialization. This preserves current behavior because the instance of ForwardRef<InputBase<string>> is created once at declaration and is not reassigned anywhere else in the snippet; the tests only modify or access its internal state via NameRef.Current, which is unaffected by the readonly modifier on the containing field.

Concretely, in src/BlazorWebFormsComponents.Test/Validations/SetFocusOnErrorTests.razor, update the field declaration on line 6 from ForwardRef<InputBase<string>> NameRef = ... to readonly ForwardRef<InputBase<string>> NameRef = .... No additional imports, methods, or other code changes are required because readonly is a simple modifier on the existing field and does not alter how it is used elsewhere.

In general, to fix a "Missed 'readonly' opportunity" issue, you add the readonly modifier to the field declaration, provided the field is only assigned at declaration or in constructors of the same class. This prevents accidental reassignment later in the object’s lifetime.

For this specific file, we should modify the declaration of Name on line 4 to include the readonly keyword. No other behavior changes are required, and no additional methods or imports are needed. The change is local to src/BlazorWebFormsComponents.Test/Validations/ValidationSummary/ValidationSummaryTests.razor, within the @code block, and will not affect how Name is used (Name.Current and @Name remain valid). Only that single field needs to be updated per the reported diagnostic.

To fix the issue, we should add the readonly modifier to the exampleModel field so that its reference cannot be reassigned after initialization. This preserves existing behavior because the field is only assigned once at declaration, and the tests simply use it as the Model of the EditForm. The Name property inside ExampleModel remains mutable, so no change is needed there.

Concretely, in src/BlazorWebFormsComponents.Test/Validations/ValidationSummary/ValidationSummaryTests.razor, within the @code block near the bottom, change the declaration:

private ExampleModel exampleModel = new ExampleModel();

to:

private readonly ExampleModel exampleModel = new ExampleModel();

No additional methods, imports, or definitions are required, and no other fields are mentioned by CodeQL in the prompt, so they are left unchanged.

To fix the problem, we should add the readonly modifier to the Name2 field declaration so that its reference cannot be reassigned after initialization. This enforces the intended immutability of the field reference while still allowing the ForwardRef<InputBase<string>> instance itself to function normally.

Concretely, in src/BlazorWebFormsComponents.Test/Validations/ValidationSummary/ValidationSummaryTests.razor, update the declaration at line 97 from ForwardRef<InputBase<string>> Name2 = new ForwardRef<InputBase<string>>(); to readonly ForwardRef<InputBase<string>> Name2 = new ForwardRef<InputBase<string>>();. No other code changes, imports, or method definitions are needed, since we are only tightening the mutability of the field reference and not changing its type or initialization.

To fix the issue, the exampleModel2 field should be marked readonly because it is only assigned at declaration and never reassigned. This communicates that the reference to the ExampleModel instance will not change after initialization and prevents accidental reassignment in the future.

Concretely, in src/BlazorWebFormsComponents.Test/Validations/ValidationSummary/ValidationSummaryTests.razor, locate the declaration:

private ExampleModel exampleModel2 = new ExampleModel();

and change it to:

private readonly ExampleModel exampleModel2 = new ExampleModel();

No additional methods, imports, or definitions are needed, and this change does not alter existing behavior: the object instance remains mutable (its Name property can still be changed), only the field reference itself becomes immutable.

In general, to fix a "Field can be readonly" issue, you add the readonly modifier to the field declaration, provided the field is only assigned at its declaration or in constructors of the same class and is not intended to be reassigned later.

Here, the field in question is ForwardRef<InputBase<string>> Name3 = new ForwardRef<InputBase<string>>(); on line 102. To fix the issue without changing behavior, we should mark this field as private readonly (or just readonly, which defaults to private in this context, but matching the other fields’ style with private is clearer). No other code changes are required since uses of Name3 do not reassign the field, they only use its members (Name3.Current). The file to edit is src/BlazorWebFormsComponents.Test/Validations/ValidationSummary/ValidationSummaryTests.razor, and the only needed change is to add the readonly modifier to Name3’s declaration.

In general, to fix a "Missed 'readonly' opportunity" for a field, you add the readonly modifier to the field declaration when the field is only assigned at its declaration or in the class constructor. This prevents later unintended reassignments of the field reference while leaving the mutability of the object it points to unchanged.

For this specific case, in src/BlazorWebFormsComponents.Test/Validations/ValidationSummary/ValidationSummaryTests.razor, the field exampleModel3 at line 103 is initialized once and never reassigned. The best fix is to add the readonly modifier to its declaration: change private ExampleModel exampleModel3 = new ExampleModel(); to private readonly ExampleModel exampleModel3 = new ExampleModel();. No other lines, methods, or imports are required, and runtime behavior remains the same because the ExampleModel instance is still mutable; only the field reference cannot be changed after initialization.

In general, to fix a "field can be readonly" issue, you add the readonly modifier to the field declaration if the field is only ever assigned in its declaration or constructors of the same class. This guarantees it cannot be accidentally modified after initialization.

For this specific case, the best fix is to add the readonly modifier to the Name4 field declaration in src/BlazorWebFormsComponents.Test/Validations/ValidationSummary/ValidationSummaryTests.razor. The declaration currently is:

ForwardRef<InputBase<string>> Name4 = new ForwardRef<InputBase<string>>();

Change it to:

readonly ForwardRef<InputBase<string>> Name4 = new ForwardRef<InputBase<string>>();

This leaves the initialization and all usages in the Razor tests unchanged, preserves existing functionality, and simply enforces immutability of the field reference after construction. No additional methods, imports, or definitions are needed.

In general, to fix a "missed 'readonly' opportunity" warning, you add the readonly modifier to a field that is only assigned at its declaration or within constructors of the same class, ensuring the field reference cannot be reassigned after initialization while leaving mutations of the object it references unaffected.

For this specific case, the best fix is to add the readonly modifier to the exampleModel4 field in ValidationSummaryTests.razor. The field is declared near the bottom of the @code block as private ExampleModel exampleModel4 = new ExampleModel();. We should change this to private readonly ExampleModel exampleModel4 = new ExampleModel();. This keeps the current behavior: the ExampleModel instance itself can still have its Name property set via data binding, but the exampleModel4 reference cannot be reassigned to a different ExampleModel instance. No additional methods, imports, or definitions are needed; we only change the field declaration modifier.

To fix the issue, make the _NameRef_ field immutable by adding the readonly modifier to its declaration. In general, any private field that is only ever assigned at the declaration site or within constructors can be marked readonly to prevent accidental reassignment later in the object’s lifetime.

Concretely, in src/BlazorWebFormsComponents.Test/Validations/ValidatorDisplayTests.razor, within the @code block near the top of the file, update the field declaration on line 6 from ForwardRef<InputBase<string>> NameRef = new ForwardRef<InputBase<string>>(); to readonly ForwardRef<InputBase<string>> NameRef = new ForwardRef<InputBase<string>>();. No additional usings, methods, or definitions are needed because readonly is a standard C# modifier and does not change how the existing code uses NameRef (all uses are reads, not writes).