Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Support autoGrantPermissions and autoAcceptAlerts for handling native popups

Abierto
  • ¿Algo no está bien?
#175 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
android, ios, playwright, typescript
Área
mobile-dev, testing-qa

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
TypeScript
Estrellas
411
Forks
66
Merge medio
1 d 21 h
PR fusionados (30 d)
61

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de mobile-next/mobilewright

Todos los issues de mobile-next/mobilewright

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.