fix(ui5-shellbar): ignore non-ShellBarItem children in overflow calculation

[dobrinyonkov]

Problem

Placing a non-ShellBarItem element (e.g. a bare <span>) in ui5-shellbar's default slot alongside the normal items causes resize to throw an uncaught error once the ShellBar's width crosses the overflow breakpoint a few times:

Uncaught Error: Web component processed too many times this task, max allowed is: 10
    at RenderQueue.process (RenderQueue.ts:62:11)
    at Render.ts:81:30

Minimal repro:

<ui5-shellbar notifications-count="72" show-notifications>
  <ui5-button icon="menu2" slot="startButton"></ui5-button>
  <ui5-shellbar-branding slot="branding">
    Product Identifier
    <img slot="logo" src="…" />
  </ui5-shellbar-branding>
  <ui5-shellbar-search slot="searchField" …></ui5-shellbar-search>
  <span></span>                                          <!-- the problem child -->
  <ui5-avatar slot="profile"><img src="…"/></ui5-avatar>
</ui5-shellbar>

Verified in Chrome: oscillating the ShellBar's width between ~320 px and ~700 px (i.e. across the overflow breakpoint) reliably fires the RenderQueue error.

Root cause

The default items slot is typed HTMLElement, so the stray <span> lands in this.items. The overflow algorithm in ShellBarOverflow.buildActions and the items-overflow-state loop in ShellBar.handleUpdateOverflowResult then assume every entry is a ShellBarItem and read item._id / item.stableDomRef. On a bare <span> both are undefined, so:

1. buildActions creates a hidable entry with id: undefined and selector: '[data-ui5-stable="undefined"]' — a selector that never matches anything in shadow DOM.
2. hiddenItemsIds ends up containing undefined and is written back into the reactive hiddenItemsIds property, which invalidates the component and re-enters the render queue inside the same task.
3. ShellBarTemplate.tsx renders <div key={item._id} …> for the span — i.e. key={undefined} — so the wrapper churns on every pass and widths never converge.

After 10 re-entries RenderQueue throws (MAX_PROCESS_COUNT = 10).

Fix

Introduce an isInstanceOfShellBarItem duck-typing checker (matching the existing createInstanceChecker pattern used across the repo) and a single _validItems accessor on ShellBar that filters this.items through it. Every read site that previously walked this.items for overflow purposes now goes through _validItems:

• ShellBar.updateOverflow — customItems passed to the algorithm
• ShellBar.handleUpdateOverflowResult — the inOverflow update loop
• ShellBar.overflowItems — what the overflow popover renders
• ShellBarTemplate.tsx — the custom-items .map (also kills the key={undefined} churn)

The <span> (or any non-ShellBarItem stray element) still ends up in the light DOM, it's just ignored by the overflow algorithm and the template — which is the correct behavior for a slot documented to accept ui5-shellbar-item.

Test

Added a Cypress regression test in packages/fiori/cypress/specs/ShellBar.cy.tsx that mounts the failing markup, oscillates the viewport across the overflow breakpoint, and asserts no processed too many times error fires.

Full ShellBar Cypress suite: 67 passing, 0 failing locally.

Out of scope

Could also tighten the slot type from HTMLElement to ShellBarItem so the framework rejects strays at assignment time. Left for a separate change in case anything relies on the looser slot contract.

[sap-ui5-webcomponents-release]

🚀 Deployed on https://pr-13729--ui5-webcomponents-preview.netlify.app

[sap-ui5-webcomponents-release]

🧹 Preview deployment cleaned up: https://pr-13729--ui5-webcomponents.netlify.app