fix: include controls without data-sap-ui attribute in control tree

[NakataCode]

Problem:

• sap.ui.core.HTML and similar controls that render raw HTML were invisible in the control tree because the tree walker only detected controls via the data-sap-ui DOM attribute, causing their children to appear flattened at the wrong level.

Solution:

• Added a fallback branch that matches registered UI5 Controls by cross-referencing their element registry ID with getDomRef() directly in the condition, correctly preserving parent-child hierarchy.

Related to: #343

[cla-assistant]

All committers have signed the CLA.

[plamenivanov91]

1. Performance concern — getDomRef() called on every DOM node with an id

The condition "node.id && control" will match for any DOM element that happens to have an id matching a registered UI5 element. For deeply nested DOMs this adds overhead since getDomRef() can trigger layout/reflow in some edge cases. The "typeof control.getDomRef === function" check is redundant because isA("sap.ui.core.Control") guarantees getDomRef exists on the prototype. It adds defensive noise without value. You can simplify to:

} else if (node.id && control && control.isA("sap.ui.core.Control") && control.getDomRef && control.getDomRef() === node) {

2. Swallowed exception — empty catch block

try { domRef = control.getDomRef(); } catch (e) { // getDomRef() can throw when a control is partially destroyed or mid re-render }

While the comment explains the intent, silently swallowing exceptions can hide bugs during development. Consider at minimum a console.debug or gating it behind a known condition (e.g. control.bIsDestroyed) to narrow the catch scope rather than blanket-catching everything.

3. Consider unit tests (if possible)

[NakataCode]

About the unit tests:
From my research, unit tests aren't feasible here. ToolsAPI.js is wrapped in sap.ui.define (SAP's AMD loader), which means it can't be require()'d in the Karma/browserify test environment. The only workaround is extracting the logic into a separate CommonJS module and testing that — but then the tests guard the extracted copy, not ToolsAPI.js itself. Someone could remove the change from ToolsAPI.js and the tests would still pass. That's false confidence, which is worse than no tests. Until the test infrastructure supports AMD modules, this change can't be meaningfully unit tested.