fix(FOSTestingUI): native dispatch uses the platform's pointer verb — macOS taps land - #139
Merged
Merged
Conversation
… macOS taps land On macOS, XCUIElement.tap() and every coordinate-synthesized tap dispatch without failure and never land. Measured one variable at a time on 27 beta via the probe's composite row: native tap() on the live, hittable, resolved control — action never fired; app-anchored coordinate tap — never fired; overlay-anchored coordinate tap — never fired; click() on the same control — green. The verb, not the aim, was the failure. Every native dispatch now goes through nativeTap(_:) — click() on macOS, tap() elsewhere — and tap()'s aimed branch resolves its XCUIElementSnapshot back to a live element (liveElement(matching:), by type and frame) so there is an element to receive the native gesture; the app-anchored coordinate remains the iOS-measured fallback only. Also measured: XCUIApplication.frame.origin is (inf, inf) on macOS, so appCoordinate(at:) subtracts only a finite origin. Cures both measured macOS failures: the generated client-server app's interaction tests (tap -> stub-op recorded), and the probe README's 'synthesized taps on native-bridged bar items do not land' regression — the probe's macOS tab + toolbar tap tests pass again (9/9).
RowResolutionTests proved the aimed dispatch only via keyboard arrival, which cannot run on macOS — the coverage hole the macOS tap failure lived in. actionRow is a caption + untagged-button composite (the row tag is the button's only route, midpoint in the caption, forcing the aimed path everywhere); the fired count is the landing proof, keyboard-free. The claim now runs in both harnesses: RowResolutionTests (iOS) and RowResolutionMacTests (macOS) — the macOS one is the test that falsified two earlier fix designs before click() was measured as the landing verb. Measured while here (Xcode 27 beta -> iOS 27 sim): the bannerToggle conditional-branch pair fails identically with and without the fix — pre-existing on this beta, not a regression.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The failure
On macOS,
uiTestingElement(_:).tap()dispatches without failure and the control's action silently never fires. Surfaced by a generated FOSMVVM client-server app: every interaction UI test (tap → stub-op recorded) failed on the macOS destination while the identical tests were green on the iOS simulator.Root cause — measured one variable at a time
Via the probe's new composite-row scenario (
RowResolutionMacTests), on macOS 27 beta:tap()on the live, hittable, resolved control — action never firedclick()on the same control — greenThe verb, not the aim, was the failure. Two supporting measurements:
XCUIApplication.frame.originis(inf, inf)on macOS (so app-anchored offset arithmetic must guard for a non-finite origin), and the aimed path'sXCUIElementSnapshothas geometry but no gestures (so a live element must be resolved to receive the native gesture).The fix
nativeTap(_:)—click()on macOS,tap()elsewhere.tap()'s aimed branch resolves its snapshot back to a live element (liveElement(matching:), by type and frame); the app-anchored coordinate remains the iOS-measured fallback only.appCoordinate(at:)subtracts only a finite origin.iOS behavior is unchanged: its verb remains
tap(), its origin is zero, and its measured-green app-anchored fallbacks are untouched.This also cures the "synthesized taps on native-bridged bar items do not land" regression recorded in the probe README on this beta — the macOS tab and toolbar tap tests pass again; the README's measurement record is updated.
New probe coverage
RowResolutionTestsproved the aimed dispatch only via keyboard arrival, which cannot run on macOS — the coverage hole this bug lived in. The new keyboard-free proof (caption + untagged-button composite; the fired count is the landing evidence) runs in both harnesses:RowResolutionTests(iOS) andRowResolutionMacTests(macOS). The macOS test falsified two earlier fix designs beforeclick()was measured as the landing verb.Verification
click()) fired wheretap()did not, in the same run — the originating evidencebannerTogglepair failed identically with and without the fix on stale simulators, and passed on fresh onesRelease note
Target: 0.13.3. Generated projects reference FOSUtilities with
from:, so they pick this up on a package update without regeneration.