You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Apply launchApp permissions after clearing simulator app state, with all: allow by default and specific overrides honoured (related: #147).
Validated with regression tests, the driver race suite and iOS picker/negative checks; full checks remain blocked by existing lint/cancellation failures and a browser startup timeout.
Thanks @s4lmon, this is the right direction. The native iOS driver is the only one
that never touches permissions on launch today, so the same flow shows a system
dialog here and none on WDA or Android. Closing that gap is worth doing, and the
ordering fix in handleSetPermissions (apply all before the specific overrides)
catches a latent bug in the existing code that map iteration could trigger at random.
Two things before I merge, both about matching what the WDA driver already does in pkg/driver/wda/commands.go (launchApp, around line 929), since that path has been
running on simulators for a long time and users expect the two drivers to behave alike:
Do not abort the launch on a simctl privacy failure. WDA ignores errors from applyIOSPermission and carries on. With this PR one unsupported service name, or
a simctl quirk on a particular Xcode, stops every flow at its first step. Log a
warning with the simctl output and continue with the launch.
Reset before granting. WDA resets every known service first, then applies the
requested values. This PR only grants, so on a launchApp without clearState a
permission the flow does not mention keeps whatever state the previous run left it
in, and a deny from an earlier flow leaks into the next one.
One smaller point: WDA expands all into its explicit list of seven services rather
than passing all to simctl. I do not know of a case where grant all behaves
differently, but if you have a simulator handy, a quick run of a flow with clearState: true and no permissions: on the native driver, checking that no
dialog appears, would settle it. I will do the same on my side before release.
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
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.
Apply
launchApppermissions after clearing simulator app state, withall: allowby default and specific overrides honoured (related: #147).Validated with regression tests, the driver race suite and iOS picker/negative checks; full checks remain blocked by existing lint/cancellation failures and a browser startup timeout.