Type
Bug (ui). Purely visual — no functional impact. Navigation, links, and file access all work.
Summary
In the content-collection file browser, the table rows are rendered too tall — each row has
excess height with the cell content top-aligned and empty space above it. The effect
worsens the deeper you navigate: the collection root looks normal, one folder level in
the rows are already ~3× too tall, and it grows further with depth. It is deterministic and
persists across a hard refresh (so it is not a client-side re-render artifact).
Screenshots
Level 0 (behavior as expected)
Level 1
Level 2
Steps to reproduce
- Open a content collection root, e.g.
/{space}/content/ — rows look normal.
- Navigate into a folder, e.g.
/{space}/content/FolderA — rows are ~3× taller, with
whitespace above the content.
- Go deeper (
/{space}/content/FolderA/SubfolderB) — taller still.
- Hard-refresh (F5) any of these deep URLs directly — the excess height remains.
Renderer / code path
A folder path renders the file browser, not the node shell:
src/MeshWeaver.ContentCollections/CollectionNamedLayoutArea.cs → Render/Browser
builds a FileBrowserControl(collectionName).WithPath(path) for any folder path.
src/MeshWeaver.Blazor/FileExplorer/FileBrowser.razor:91 renders the rows as a
<FluentDataGrid Items="..." ResizableColumns="true" ShowHover="true"> with a Name and a
Details TemplateColumn.
- Scoped styles:
src/MeshWeaver.Blazor/FileExplorer/FileBrowser.razor.css.
DOM evidence
The Name cell content is a single-line anchor (icon + label) — inherently ~20 px:
<div class="grid-item">
<a href="/{space}/content/FolderA/SubfolderB" class="file-browser-link">
<svg style="width: 20px; fill: var(--accent-fill-rest);" ...>…</svg>
<span>SubfolderB</span>
</a>
</div>
So the excess height is not in the cell content (and .grid-item has no height rule in
the scoped CSS). It is on an ancestor — the <fluent-data-grid-row> / <fluent-data-grid>
being taller than the content.
Diagnostic findings (what has been ruled out)
- Not a spacing rule in this component.
FileBrowser.razor.css uses only fixed values
(.folder-list/.file-list { gap: 10px }, .folder-item { gap: 5px; padding: 5px 10px }),
and there is no .grid-item/row-height rule.
- Not depth-dependent code. The same
FileBrowserControl → FluentDataGrid with
identical templates renders at every level; only the current path (breadcrumb segments)
and the item list differ. There is no depth- or path-driven layout branch in the source.
- Not re-render accumulation. A hard refresh of a deep URL reproduces it, so it is not
grid-template-rows accumulating across client-side navigations.
- No global CSS stretches the grid rows (searched
src/**/*.css for grid-template-rows
/ row-height rules targeting the DataGrid — none apply to this browser).
Leading hypothesis (to confirm in the DOM)
The FluentDataGrid rows appear to be stretched to fill a height rather than sized to
content: the grid (or its container) has a definite height, and the rows are distributed
across it. Folders with fewer items therefore render each row taller (fewer rows
sharing the same vertical space, content top-aligned → whitespace above). Because deeper
folders tend to have fewer items, the effect grows with depth — consistent with the
hard-refresh-deterministic behaviour.
Implementer confirmation step: inspect <fluent-data-grid> and read its computed
grid-template-rows (and a row's computed height). Expected tell: grid-template-rows
contains 1fr/surplus tracks (stretch), rather than content-height (auto/min-content)
tracks — and the applied height rule comes from FluentUI's own stylesheet or an ancestor
that gives the grid a full height.
Proposed fix direction (src/ change)
Constrain the file-browser grid so rows size to content and pack to the top, via a scoped
::deep rule in src/MeshWeaver.Blazor/FileExplorer/FileBrowser.razor.css, e.g.:
::deep fluent-data-grid {
grid-auto-rows: min-content; /* rows size to content, not stretched */
align-content: start; /* pack rows to the top of the grid */
}
Note: FluentDataGrid may set grid-template-rows inline from its own JS, so verify the
override actually wins (raise specificity / target the generated rows if needed), and
re-check the computed grid-template-rows after the change. The goal: row height equals
content height at every folder depth, with no whitespace above the content.
Acceptance criteria
- Folder rows are content-height at the collection root and at every nesting depth — no
excess height and no whitespace above the cell content.
- The row height does not vary with the number of items in a folder.
- Verified on a fresh (hard-refreshed) deep URL, not only after in-app navigation.
- Navigation, selection, download, and links continue to work (no functional regression).
Type
Bug (
ui). Purely visual — no functional impact. Navigation, links, and file access all work.Summary
In the content-collection file browser, the table rows are rendered too tall — each row has
excess height with the cell content top-aligned and empty space above it. The effect
worsens the deeper you navigate: the collection root looks normal, one folder level in
the rows are already ~3× too tall, and it grows further with depth. It is deterministic and
persists across a hard refresh (so it is not a client-side re-render artifact).
Screenshots
Level 0 (behavior as expected)
Level 1
Level 2
Steps to reproduce
/{space}/content/— rows look normal./{space}/content/FolderA— rows are ~3× taller, withwhitespace above the content.
/{space}/content/FolderA/SubfolderB) — taller still.Renderer / code path
A folder path renders the file browser, not the node shell:
src/MeshWeaver.ContentCollections/CollectionNamedLayoutArea.cs→Render/Browserbuilds a
FileBrowserControl(collectionName).WithPath(path)for any folder path.src/MeshWeaver.Blazor/FileExplorer/FileBrowser.razor:91renders the rows as a<FluentDataGrid Items="..." ResizableColumns="true" ShowHover="true">with a Name and aDetails
TemplateColumn.src/MeshWeaver.Blazor/FileExplorer/FileBrowser.razor.css.DOM evidence
The Name cell content is a single-line anchor (icon + label) — inherently ~20 px:
So the excess height is not in the cell content (and
.grid-itemhas no height rule inthe scoped CSS). It is on an ancestor — the
<fluent-data-grid-row>/<fluent-data-grid>being taller than the content.
Diagnostic findings (what has been ruled out)
FileBrowser.razor.cssuses only fixed values(
.folder-list/.file-list { gap: 10px },.folder-item { gap: 5px; padding: 5px 10px }),and there is no
.grid-item/row-height rule.FileBrowserControl→FluentDataGridwithidentical templates renders at every level; only the current path (breadcrumb segments)
and the item list differ. There is no depth- or path-driven layout branch in the source.
grid-template-rowsaccumulating across client-side navigations.src/**/*.cssforgrid-template-rows/ row-height rules targeting the DataGrid — none apply to this browser).
Leading hypothesis (to confirm in the DOM)
The
FluentDataGridrows appear to be stretched to fill a height rather than sized tocontent: the grid (or its container) has a definite height, and the rows are distributed
across it. Folders with fewer items therefore render each row taller (fewer rows
sharing the same vertical space, content top-aligned → whitespace above). Because deeper
folders tend to have fewer items, the effect grows with depth — consistent with the
hard-refresh-deterministic behaviour.
Implementer confirmation step: inspect
<fluent-data-grid>and read its computedgrid-template-rows(and a row's computedheight). Expected tell:grid-template-rowscontains
1fr/surplus tracks (stretch), rather than content-height (auto/min-content)tracks — and the applied
heightrule comes from FluentUI's own stylesheet or an ancestorthat gives the grid a full height.
Proposed fix direction (src/ change)
Constrain the file-browser grid so rows size to content and pack to the top, via a scoped
::deeprule insrc/MeshWeaver.Blazor/FileExplorer/FileBrowser.razor.css, e.g.:Note: FluentDataGrid may set
grid-template-rowsinline from its own JS, so verify theoverride actually wins (raise specificity / target the generated rows if needed), and
re-check the computed
grid-template-rowsafter the change. The goal: row height equalscontent height at every folder depth, with no whitespace above the content.
Acceptance criteria
excess height and no whitespace above the cell content.