Feature/webcomponents support

[IlianaB]

Extends the UI5 Inspector to detect and inspect UI5 Web Components-based applications, alongside the existing OpenUI5/SAPUI5 support. Pages using either framework — or both — show a merged control tree with per-framework introspection.

---

What's implemented

Detection. Pages using @ui5/webcomponents are detected automatically alongside classic UI5 detection. Mixed pages report both.

Control tree. Web components are listed alongside classic UI5 controls. On mixed pages the two are merged under a single tree, with the WebC portion grouped under a synthetic root labelled with the framework name and version. Private members (names beginning with _) are filtered from properties, slots, and events to keep the panel focused on the public API. Tree updates on DOM changes are debounced (150 ms) to collapse rapid bursts.

Properties tab. Reads property metadata via element.constructor.getMetadata() and current values from the live element. Editable inline (writes back via element[name] = value).

Slots tab. On pure WebC pages the "Aggregations" tab label is renamed to "Slots". Slotted content is resolved via element[slotData.propertyName || slotName] (how the framework itself exposes slot assignments), so nested elements are surfaced with their _ids.

Events tab. Lists declared events; when an event's metadata declares a detail shape, param types are reported.

Actions tab. Focus, Copy to Console, Copy HTML to Console. Invalidate is intentionally omitted — web components re-render automatically on property/attribute changes.

App Info tab (pure WebC). General, Configuration (theme, language, timezone, animation mode, calendar type, etc.), Registered tags, Registered features, Interop (OpenUI5 detection), Runtimes (when more than one is active). Data comes from meta.Runtimes[0] (packages/base/src/Runtimes.ts). Long lists (registered tags, features) are alphabetised and emitted as arrays so DataView preserves order.

Right-click "Inspect UI5 element" in the page selects the corresponding row in the tree. The context menu label was renamed from "Inspect UI5 control" since "control" is SAPUI5 terminology.

Tree hover highlight overlays the visible element on the page. Some components (e.g. ui5-breadcrumbs-item) are light-DOM data carriers with zero rect; the highlighter walks up to the shadow root and resolves the visible representation by the framework's - convention.

---

Architecture

The existing 4-layer communication (panel ↔ background ↔ content script ↔ page-injected script) was fully reusable. New pieces:

• app/vendor/WebComponentsToolsAPI.js — introspection API. Exposes getFrameworkInformation, getRenderedControlTree, getControlProperties, getControlAggregations, getControlEvents, getElementById. Aligned with the framework source (UI5Element.ts, UI5ElementMetadata.ts): identifies web components via element.isUI5Element === true, reads the framework version from meta.Runtimes[0].version, uses element._id as the canonical id.
• app/scripts/injected/detectWebComponents.js — page-context detection.
• app/scripts/content/detectWebComponents.js — content-script that injects the detector and, once detection succeeds, acts as the message bridge between the background and the MAIN-world script.
• app/scripts/injected/webcMain.js — MAIN-world script that handles all runtime interactions (tree updates, property edits, focus, copy, right-click, tree hover). A top-of-file block comment documents the communication path and action-name conventions for future maintainers.

Script injection uses chrome.scripting.executeScript({world: 'MAIN'}) for the WebC scripts, bypassing page CSP that would block <script src> injection. This was required to support strict-CSP hosts (e.g. Fiori shell). Classic UI5 still uses the older <script src> approach.

---

Panel changes

• New message handlers: on-webc-detected, on-webc-not-detected, on-webc-script-injection, on-receiving-initial-data-webc, on-application-dom-update-webc.
• Tree merging (_getMergedControlTree) combines classic + WebC trees into one view.
• The "Aggregations" tab label is renamed to "Slots" dynamically when the current frame is pure WebC.
• App Info precedence rule on mixed pages: classic UI5 wins, since it provides richer info (loaded libraries, modules, bootstrap config, URL parameters); documented inline where the rule is applied.
• The synthetic WebC group root (webc_root) is non-selectable and non-hoverable — its handlers no-op when the id matches.
• Overlay text mentions UI5 Web Components alongside OpenUI5/SAPUI5.

---

Shared highlighter refactor

modules/content/highLighter.ts was refactored from a singleton with id-based lookup to a factory taking a resolved element:

• Classic content script: highLighter.setDimensions(document.getElementById(id)).
• WebC script: highLighter.setDimensions(WebCToolsAPI.getElementById(id)).
• Two instances coexist on mixed pages via distinct wrapperId options (ui5-highlighter and ui5-highlighter-webc) so their overlays don't collide.
• The existing highLighter.spec.js was updated to cover the new API (factory, element param, custom wrapper id).

---

Known limitations (deferred)

Two things intentionally not implemented in this PR:

1. No dropdown for enum-typed properties. For example, ui5-button's accessibleRole accepts only "Button" or "Link", but the panel renders it as a free-text input rather than a select. Reason: web components ship enum types as TypeScript-only annotations (e.g. accessibleRole: ${ButtonAccessibleRole} = "Button"), which are erased at compile time. The runtime metadata contains no enum information, and the framework does not expose enum members on any global. There is no runtime path to recover the valid values. Options considered:

• Ship the @ui5/webcomponents api.json files alongside the extension and read enum members from there — adds hundreds of KB and requires updating per WebC release.
• Ask upstream to expose enum members via a static method on UI5Element — clean fix but out of our scope.

For now the value is still editable as free text; the user just has to know the valid values.

2. No isDefault flag for WebC properties. Classic UI5 shows a "(default)" badge next to properties still holding their default value. For WebC we omit this badge because the metadata contains no defaultValue field — defaults are TypeScript class-field initialisers that, when compiled to ES2022 target, land on the instance and cannot be reliably distinguished from user-set values through prototype-chain inspection. A previous heuristic produced misleading results (e.g. selectionMode: "None" shown as non-default). The isDefault field is simply omitted; the DataView already suppresses the badge when the field is absent. A future implementation could snapshot defaults by sampling document.createElement(tag) once per tag at startup.

---

Tested against

• Pure WebC apps (DynamicPage sample from the webcomponents repo)
• Pure classic UI5 apps (no regression)
• Mixed apps using sap.f.gen.ui5.webcomponents_fiori.dist.* wrapper controls (both trees populate cleanly without duplication, since wrappers keep their web components inside shadow DOM)

[cla-assistant]

All committers have signed the CLA.