Skip to content

fix(menu): hide items of a submenu whose visible is false - #1657

Open
rene-schakmann wants to merge 1 commit into
openng-org:mainfrom
rene-schakmann:fix/issue-1648-hidden-submenu-subtree
Open

rene-schakmann wants to merge 1 commit into
openng-org:mainfrom
rene-schakmann:fix/issue-1648-hidden-submenu-subtree

Conversation

@rene-schakmann

Copy link
Copy Markdown
Contributor

Fixes #1648

Problem

A child item that set visible: true rendered even when its parent submenu had visible: false:

@if (!item.separator && item.visible !== false && (item.visible !== undefined || submenu.visible !== false))

The item.visible !== undefined clause force-shows any child that declares visible. The group header (li[data-pc-section="submenulabel"]) is gated on submenu.visible !== false alone, so it does not render — the force-shown item is left with no group label at all, which is the a11y gap reported in #1648.

The sibling separator guard had a related bug, an || where it needs &&:

@if (item.separator && (item.visible !== false || submenu.visible !== false))

With a hidden group and a separator that leaves visible undefined, item.visible !== false is true, so separators rendered inside a hidden group.

Fix

Move the child loop inside the @if (submenu.visible !== false) wrapper added in #1632 and drop the parent checks from the inner conditions. A hidden group now hides its header, its separators and its items alike, and the grouped branch reads exactly like the non-grouped one.

The item li bindings, menuitemId() ids, data-pc-section values and PT hooks are unchanged. git log -S traces the escape hatch back to the pre-fork PrimeNG rename (0c463b7410) — it is undocumented and was never a deliberate feature here.

Behavior change worth a look: item.visible: true no longer overrides a hidden parent group. Anyone relying on the force-show loses those items.

Tests

Three cases added next to the ones from #1632:

  • hidden group with a visible: true child renders no items and no orphan (fails before the fix: expected 2 to be 1)
  • hidden group containing a separator renders no separators (fails before the fix: expected 1 to be +0)
  • a visible: true child of a visible group still renders, so the fix does not overreach

Menu suite: 131 passed. Full optimus-ui suite: 7281 passed, 90 skipped, 0 failed.

Verified in the docs app

Group demo temporarily patched with the issue's repro model (Documents group visible: false, child Forced Visible Item visible: true), reverted afterwards.

Before: Forced Visible Item renders on its own, no Documents header above it.
After: the entire hidden group is gone, only the Profile group remains.

Follow-up

isItemHidden() (menu.ts:942) is dead code and carries its own inverted separator logic. Left untouched here; happy to remove it separately if you want it gone.


Co-authored by Claude. (The trailer is in the description rather than the commit because commitlint's no-ai-co-author rule rejects it in the message.)

A child item that set `visible: true` rendered even when its parent
submenu had `visible: false`, because the guard allowed any child with a
defined `visible`. The group header is gated on the submenu alone, so the
force-shown item was left with no group label at all.

Move the child loop inside the existing submenu visibility check, so a
hidden group hides its header, separators and items alike, matching the
non-grouped branch. This also fixes the child separator guard, which used
`||` and therefore rendered separators inside a hidden group.

Fixes openng-org#1648
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

a11y: force-shown item under a hidden submenu group has no accessible group label

1 participant