Inspector

The tab at a glance

Open the FrontTailor panel in DevTools (F12), or the side panel from the extension icon, and choose the Inspector tab. The app’s control tree is on the left, the details of the selected control on the right. In the narrow side panel they are stacked.

1. Pick control starts pick mode: then click a control in the page. Next to it, Reload tree reads the tree again.
2. Search ID, type or text – all three are searched. Matches keep their ancestors so you see where the control sits.
3. Filters: Only visible, Only bound and Only custom controls (type not from sap.*). To the right: the number of nodes and how long reading took.
4. The control tree: UI areas, components, views and controls in the app’s order. Arrow keys move the selection.

The tree follows the running app: when the app opens a dialog or loads more list items, the new controls appear by themselves. For very large apps the inspector shows up to 20,000 nodes; beyond that it says “Tree truncated: only the first … nodes are shown.”

Pick a control in the page

1. Click Pick control or press Alt+Shift+F – the shortcut also works with DevTools closed and then opens the side panel.
2. Move the mouse over the app. A frame shows the control under the pointer with type, ID and – if bound – the binding path.
3. Click the control. The app does not see the click: no button fires, no popover closes. Esc cancels.
4. The inspector jumps to the control in the tree and shows its details on the right.

This also works in dialogs, popovers and apps that run in an iframe inside the launchpad. A click in a frame switches the inspector to that frame; the Frame selector above the tree shows which one is meant (Top frame is the page itself).

Details of a control

1. Type and ID, below them view and component. Next to them, API reference opens the class in the UI5 documentation of exactly the version the app loads; Fiori Design Guidelines opens the matching guidelines page if there is one.
2. Parent chain: every ancestor up to the UI area, clickable.
3. Copy as… – ID, OPA5 selector, wdi5 selector, Playwright locator or XML snippet (see below).
4. Store as variable hands the control to the DevTools console (see below).
5. bound below a property name opens where the value comes from.

The details have five tabs:

Property, aggregation and event names in the tables link to their entry in the API reference of the class that declares them. If a control is not in the tree – say a dialog that was never opened – a note in the details explains why and names the root.

Where does the value come from? Reading bindings

1. Select the control (pick or search).
2. In the Properties tab, click bound below the property name.
3. The Binding of … popover shows the path as written, Resolved path, model, Model type (OData V2, OData V4, JSON, Resource (i18n), XML), Value in the model, Current value, binding mode, type and formatter – for i18n texts key and text.
4. Copy path takes the path with you, Show in Bindings tab highlights the row in the Bindings tab, Show in Model Explorer opens the Model explorer tab right at that spot.

1. Path as written in the view.
2. Model type – here a resource model with the i18n texts.
3. Copy path.
4. Show in Bindings tab.

When a field stays empty, the tab usually tells you why: “not resolved” means the control has no model or context yet – typical for a relative path without an element binding.

Edit properties live

In the Properties tab every value is an editor: booleans as check boxes, enums as a select, numbers as a number field, everything else as a text field. Objects and arrays stay read-only.

• Enter or leaving the field applies the value; Esc brings back the page’s value.
• The inspector checks the value against the data type. If it does not fit, you see “Invalid value: …” and the control keeps its value.
• For bound properties a note warns: “Bound: the next model update overwrites a change.” With TwoWay bindings the change is written to the model, too.

Copy selectors and XML

Generated IDs such as __button3 never end up in a selector. Instead the inspector uses the control type and a feature that makes the control unique: a text, an i18n key or a binding path. The automated tests run the selectors against the demo apps.

Store as variable (DevTools console)

1. Select the control and click Store as variable.
2. The inspector stores it as $ft0 (the next one as $ft1 …, the latest always also as $ft) and shows an example call such as $ft0.getText().
3. Switch to the DevTools console and use the variable. If the app runs in an iframe inside the launchpad, the inspector names the frame you have to pick at the top left of the console.

The menu next to it stores a binding context or a model instead of the control. The variables live in the page only until it reloads; FrontTailor stores none of it. Delete all clears them.

More actions in the details

• Open in editor jumps to the view’s source file in your local editor. Set up the path mapping once in Tools (namespace → local folder).
• Show in Elements panel selects the control’s DOM element in the DevTools Elements panel.
• With from Pro you also get the AI entries Explain control, Why not visible? and wdi5 test – with your own key, see AI assistant.

Typical problems