Support autoGrantPermissions and autoAcceptAlerts for handling native popups

[Dhakshath11]

Problem or motivation

When testing real apps, almost every first-launch flow is blocked by native OS prompts — runtime permission dialogs (location, camera, notifications, photos, microphone), system consent sheets, and app-level modals (cookie banners, onboarding, "Rate us").

Today there is no first-class way to handle these in mobilewright. Each test has to:

1. Wait for the prompt to render,
2. Locate the "Allow" / "OK" / "Don't Allow" button by text or role,
3. Tap it,
4. Repeat for every permission the app requests on launch.

This is boilerplate every test author rewrites, it's fragile (button text varies by OS version and locale — "Allow Once" vs "Allow While Using App" vs "OK"), and on simulators/emulators the same prompt fires every fresh install. Appium addresses this with autoAcceptAlerts / autoGrantPermissions capabilities; mobilewright currently does not.

Without a built-in mechanism, the realistic alternatives are:

• Pre-grant via adb shell pm grant (Android) or xcrun simctl privacy grant (iOS simulator) — covers only manifest-declared OS permissions, doesn't help on iOS real devices, doesn't cover app-level modals.
• Manual tap chains in every test — repetitive, breaks under OS-version drift.

---

Proposed solution

Two complementary additions:

1. autoGrantPermissions — automatically accept OS runtime permission prompts on test startup.

// In playwright.config.ts equivalent / project config
export default defineConfig({
  use: {
    autoGrantPermissions: true,
    // or selective:
    autoGrantPermissions: ['camera', 'location', 'notifications'],
  },
});

Behavior:

• true → accept all OS permission prompts when they appear.
• string[] → accept only the listed services; ignore the rest (test author handles them explicitly or fails on timeout).
• Default false → no change from current behavior.

2. autoAcceptAlerts / autoDismissAlerts — handle generic alert/confirm/permission popups during the test.

export default defineConfig({
  use: {
    autoAcceptAlerts: true,   // tap the primary affirmative button
    // or
    autoDismissAlerts: true,  // tap the cancel/secondary button
  },
});

Behavior:

• true → on any alert that appears mid-test, automatically tap the affirmative (accept) or secondary (dismiss) button.
• Default false.

Both options should be configurable per-test (test.use({ autoAcceptAlerts: true })) and per-project, matching Playwright's config inheritance.

Expected ergonomics: a test that today reads —

await device.launchApp('com.example.app');
await screen.getByText('Allow').tap();           // location prompt
await screen.getByText('Allow').tap();           // notifications
await screen.getByText('Continue').tap();        // onboarding
await screen.getByText('Find nearby').tap();

— becomes:

// config: autoGrantPermissions: true
await device.launchApp('com.example.app');
await screen.getByText('Find nearby').tap();

---

Target platform

Platform-agnostic

Alternatives considered

1. adb shell pm grant / xcrun simctl privacy grant documented as the recommended approach. Rejected as the primary solution:

• Doesn't work on iOS real devices.
• Only covers OS runtime permissions, not app-level modals (cookie banners, in-app consent, "Rate us" prompts).
• Pushes platform-specific shell-out into every user's test setup.

Still worth shipping as an optional helper for the predictable-permission case, but not a substitute.

2. Document a "tap the button by role" recipe and leave it to test authors. Rejected — that's what users do today, and it's exactly the boilerplate this issue exists to remove. It also doesn't survive OS-version button-label changes.

3. Add a single coarse autoAcceptAlerts: true capability (Appium-style) without autoGrantPermissions. Workable for a first iteration, but coarse — it would also accept destructive prompts ("Delete all photos?"). Better to split permissions from generic alerts so users can opt into the safe subset.

---

Additional context

Target platform

Both iOS and Android. The implementation paths differ:

• Android — autoGrantPermissions can be implemented cheaply via adb shell pm grant at app-launch time for manifest-declared runtime permissions. autoAcceptAlerts needs on-device detection (UiAutomator UiWatcher or equivalent).
• iOS simulator — autoGrantPermissions via xcrun simctl privacy grant.
• iOS real device — no OS-level escape hatch; both options require on-device detection through the agent (XCUITest, similar to Appium's FBAlertsMonitor).

This RFC requests the feature surface; the implementation strategy per platform can be settled during design.

---

Additional context

• Appium's prior art: autoAcceptAlerts / autoDismissAlerts capabilities and the on-device implementation in FBAlertsMonitor.m.
• Reproduction app for the iOS permission-prompt flow: Playground v1.0.3 (shared by @gil Megidish in the related Slack discussion).
• Playwright analogue for shape comparison: page.on('dialog') — same surface area (programmatic accept/dismiss), different transport assumptions.

[gmegidish]

Just updating here as well.

I think we're better off doing playwright's implementation, page.on("dialog") or screen.on("alert", (alert) => {}); If a developer has to look in the documentation anyway for magic keywords like "autoGrantPermissions", they can look up in documentation and copy a 2 line sample callback.

The reason I believe it's better to do callback, besides the parity with playwright, is that you might want to assert things on the alert. Like it's locale, maybe the order, how does it behave after an app version upgrade, and so on.

This is on the roadmap. Thank you for creating the issue. I'll update here.