Bug Description

If you change a slot (add, remove an element to the slot) not only the changed slot is invalidated, but other unchanged slots are being invalidated as well.
This leads to issues if you want to use onInvalidation to listen for specific slot invalidations.

Affected Component

UI5Element

Expected Behaviour

I'd expect only slots that have actually changed to be invalidated and unchanged slots to not be part of the invalidation process.

In the given example, I'd expect the counter to not go up, as the noChange slot has not changed at all, but it is going up indicating an unnecessary invalidation here.

Isolated Example

https://stackblitz.com/edit/stackblitz-starters-9w5uuhan?file=src%2FMyComponent.ts

Steps to Reproduce

1. Open https://stackblitz.com/edit/stackblitz-starters-9w5uuhan?file=src%2FMyComponent.ts
2. Click on the "Add item to default slot" button => This will add a span element to the default slot of MyComponent
3. Observe the counter going up, although it should only go up when noChange is invalidated

Log Output, Stack Trace or Screenshots

No response

Priority

Medium

UI5 Web Components Version

2.5.0

Browser

Chrome

Operating System

MacOS Sequoia 15.1.1

Additional Context

UI5Element#_updateSlots is called twice, which leads to slotsCachedContentMap.get("noContent") to be empty on second call, leading to a mismatch with this._state["noContent"].
(You can check this yourself by adding a conditional breakpoint in UI5Element#_updateSlots Line 949 propertyName === "noChange")

Seems like _processChildren is called twice.
Once probably by the DOMObserver (as the stack trace shows the index.html as origin) and the second time by _onShadowRootSlotChange

Organization

UI5 Tables (SAP SE)

Declaration

• I’m not disclosing any internal or sensitive information.