Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Support autoGrantPermissions and autoAcceptAlerts for handling native popups

Aperta
  • Qualcosa non va?
#175 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
android, ios, playwright, typescript
Ambito
mobile-dev, testing-qa

Direzione di ricerca

Start by reading the project’s configuration and app-launch paths, then trace how its Android and iOS agents interact with system alerts; the issue does not name specific files or tests. The proposed behavior spans config inheritance and distinct platform implementations, with real-device permission prompts requiring on-device detection. Done means both options work per project and per test across iOS and Android, with the stated defaults and selective permission behavior.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
TypeScript
Stelle
411
Fork
66
Merge medio
2g 1h
PR unite (30g)
56

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di mobile-next/mobilewright

Tutte le issue di mobile-next/mobilewright

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.