Mobilewright version
mobilewright / @mobilewright/test / @mobilewright/core / @mobilewright/driver-mobilecli: 0.0.50 Underlying mobilecli: 0.3.85, on-device agent com.mobilenext.devicekit v1.2.2
Operating system
macos
Target platform
Android
Device or simulator
Android emulator — "Medium Phone API 36.1", Android 16 (API 36), 1080×2400
Minimal reproduction
- Any Flutter app screen with a clickable icon-only child element (no text/content-desc) nested inside a clickable, labeled parent — e.g. a "+" add-to-cart button inside a package row whose row itself has a content-desc.
- Confirm via raw adb shell uiautomator dump that the child exists with NAF="true", clickable="true", and valid bounds:
<node NAF="true" index="4" text="" resource-id="" class="android.view.View" package="customer" content-desc="" clickable="true" ... bounds="[852,1214][980,1302]" />
- Run mobilecli dump ui --device against the same screen state.
- Inspect the parent row's node in the JSON output — its children array is empty ([]).
- Open the mobilewright inspector (http://127.0.0.1:4621) on the same screen and click directly on the button's location in the live device mirror.
Actual behavior
1- mobilecli dump ui omits the NAF="true" node entirely — it's absent from the tree at any depth, and a full recursive bounds search over the dump finds nothing near its known coordinates.
2- The mobilewright inspector (backed by the same tree data) shows no locator entry for it, and clicking its exact pixel location in the device mirror produces no highlight, no picked element, and no change in the reported element count.
3- Consequently, no mobilewright locator strategy (getByRole, getByType, getByLabel, getByTestId) can resolve or tap this element — it's structurally invisible to the framework, not a query-syntax problem.
Expected behavior
NAF-flagged-but-clickable="true" nodes should be included in the dumped tree (at minimum behind an opt-in flag), so mobilewright locators can target unlabeled-but-interactive elements. Other UiAutomator2-based tools (e.g. Appium via WebdriverIO) preserve these nodes in their page source and can target them via XPath (//android.view.View[@Clickable='true']) without issue.
Additional context
This specifically affects Flutter apps, which commonly render custom icon-only controls as bare android.view.View/android.widget.Button nodes with no accessible label — a "+" quantity button was the case hit here, but any icon-only tappable control in a Flutter app is likely affected the same way.
Mobilewright version
mobilewright / @mobilewright/test / @mobilewright/core / @mobilewright/driver-mobilecli: 0.0.50 Underlying mobilecli: 0.3.85, on-device agent com.mobilenext.devicekit v1.2.2
Operating system
macos
Target platform
Android
Device or simulator
Android emulator — "Medium Phone API 36.1", Android 16 (API 36), 1080×2400
Minimal reproduction
<node NAF="true" index="4" text="" resource-id="" class="android.view.View" package="customer" content-desc="" clickable="true" ... bounds="[852,1214][980,1302]" />
Actual behavior
1- mobilecli dump ui omits the NAF="true" node entirely — it's absent from the tree at any depth, and a full recursive bounds search over the dump finds nothing near its known coordinates.
2- The mobilewright inspector (backed by the same tree data) shows no locator entry for it, and clicking its exact pixel location in the device mirror produces no highlight, no picked element, and no change in the reported element count.
3- Consequently, no mobilewright locator strategy (getByRole, getByType, getByLabel, getByTestId) can resolve or tap this element — it's structurally invisible to the framework, not a query-syntax problem.
Expected behavior
NAF-flagged-but-clickable="true" nodes should be included in the dumped tree (at minimum behind an opt-in flag), so mobilewright locators can target unlabeled-but-interactive elements. Other UiAutomator2-based tools (e.g. Appium via WebdriverIO) preserve these nodes in their page source and can target them via XPath (//android.view.View[@Clickable='true']) without issue.
Additional context
This specifically affects Flutter apps, which commonly render custom icon-only controls as bare android.view.View/android.widget.Button nodes with no accessible label — a "+" quantity button was the case hit here, but any icon-only tappable control in a Flutter app is likely affected the same way.