[lana-20]

Two gaps from the verification comments on #327 and #329.

A wait on a locked iOS device (391)

iOS reads its lock screen, so a target is simply absent from it. Three forms of wait reported success about an app nobody could see, and the rest never named the lock.

On a locked iOS simulator	Before	Now
wait X --for hidden	exit 0, "is hidden"	exit 3, names the lock
wait X --not	exit 0, "no longer visible"	exit 3, names the lock
wait X --for count --count 0	exit 0, "matches 0"	exit 3, names the lock
wait X	exit 6, "not on screen"	exit 3, names the lock
find X	exit 0, "No element matches"	exit 3, names the lock
text X	exit 4, "no element matches"	exit 3, names the lock

Android already refused all six. A wait to show still runs its timeout, for a person unlocking by hand. On an unlocked home screen these answer as before.

wait testid=table (392)

Android gave @e2 table (list) and iOS (no ref) table. This is not a regression from #330: before it, iOS returned no element at all. React Native on iOS puts the testID on a plain view around the ScrollView, on exactly the same rectangle.

A match the map filters out now takes the ref of the one mapped element on its own rectangle, in wait, scroll-to and find. A wrapper around a smaller control still has no ref, since its ref would touch something other than what matched. iOS still labels it ScrollView where Android says table.

Measured

• lock.sh and wait-states.sh fail on main on the iOS simulator and pass here on both platforms.
• locators passes on both; mobium-app and dialogs on iOS.
• A sweep of test IDs on the first screens of 14 apps gave list refs only to real list containers. 42 iOS waits did not finish within the sweep's 0.7 s limit, and were not classified.

Not settled here

• Not run on a real phone, or on an Android lock screen that stays awake.
• An Android device put to sleep from outside Mobium, then tapped by element within the half second, still reports the tap (Name the lock, however an action meets it (CHALLENGES 389) #332).