Skip to content

Add handlers for locking/unlocking the screen#21

Merged
mykola-mokhnach merged 4 commits into
masterfrom
lock
Jan 4, 2018
Merged

Add handlers for locking/unlocking the screen#21
mykola-mokhnach merged 4 commits into
masterfrom
lock

Conversation

@mykola-mokhnach

Copy link
Copy Markdown

The PR superseeds #8 by @umutuzgur
I've also added integrations tests, fixed minor issues + screen unlock for iOS < 10

if (fb_isLocked) {
return YES;
}
SEL mSelector = NSSelectorFromString(@"pressLockButton");

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mykola-mokhnach As you suggested, lets get rid of this by importing #import "XCUIDevice.h". This method exists in the private headers

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

[self pressButton:XCUIDeviceButtonHome];
[[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:FBHomeButtonCoolOffTime]];
if (SYSTEM_VERSION_LESS_THAN(@"10.0")) {
[[FBApplication fb_activeApplication] swipeRight];

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool!

return YES;
}
[self pressButton:XCUIDeviceButtonHome];
[[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:FBHomeButtonCoolOffTime]];

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you need this. Usually higher XCUITest apis already have this cool off implemented or have you seen a case that this was needed?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is a comment in the code that it was the case in 9.3. I'd rather keep the delay, since there is anyway an animation delay there and XCTest does not really like animations.

[[FBRoute POST:@"/wda/deactivateApp"] respondWithTarget:self action:@selector(handleDeactivateAppCommand:)],
[[FBRoute POST:@"/wda/keyboard/dismiss"] respondWithTarget:self action:@selector(handleDismissKeyboardCommand:)],
[[FBRoute GET:@"/lock"].withoutSession respondWithTarget:self action:@selector(handleLock:)],
[[FBRoute POST:@"/wda/lock"].withoutSession respondWithTarget:self action:@selector(handleLock:)],

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is actually a PUT since the end state is always a locked screen, I'm not considering the case of it failing since it is irrelevant in http methods. The same applies to unlock

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather follow the general pattern.

},
@"scale": @([FBScreen scale])
@"scale": @([FBScreen scale]),
@"locked": @([[XCUIDevice sharedDevice] fb_isScreenLocked])

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice idea

@umutuzgur

Copy link
Copy Markdown
Member

I'm closing my PR. Cool solution for below iOS 10!

@mykola-mokhnach

Copy link
Copy Markdown
Author

@imurchie can you please take a look at this PR?

@imurchie imurchie left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One little typo. Otherwise looks good.

/**
Checks if the screen is locked or not.

@return YES if if screen is locked

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if if

@mykola-mokhnach mykola-mokhnach merged commit d342b64 into master Jan 4, 2018
@mykola-mokhnach mykola-mokhnach deleted the lock branch January 4, 2018 15:23
followthemoney1 added a commit to FlutterFastCom/WebDriverAgent that referenced this pull request May 10, 2026
Phase-1 empirical test on iPhone 14 Pro / iOS 26.1 (2026-05-10) showed
bundle never appeared in Settings → Privacy & Security → Photos because
prior code skipped requestAuthorization on .notDetermined and treated it
as unsupported.

iOS test runners have no UI surface to display the permission prompt, so
iOS auto-denies — but the call still registers the bundle in the TCC
database. Once registered, /wda/system/photos-permission/grant (TIER 3b
endpoint appium#21, F-WDA-FORK-EXTENSIONS) can auto-navigate Settings to tap
Full Access; OR user grants manually one-time per device.

Empirically verified post-patch: /wda/photos/list returns assets,
/wda/photos/import returns valid assetIdentifier in 209ms,
/wda/photos/importBatch atomic transaction succeeds in 85ms total
across 2 assets, pushed images visible in iPhone Photos.app within 30s.

Phase-1 critical visual gate: PASSED. WDA-fork approach validated.

Refs: docs/business/features/approved/F-WDA-FORK-EXTENSIONS.md
Refs: tasks/2026-05-09-wda-fork-extensions.md Phase 1

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants