iOS: alert dismiss taps "Allow" on the App Tracking Transparency prompt
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 2/5
- Temps estimé
- 1-3 heures
- Accessibilité débutants
- 62/100
Piste de recherche
Le bogue se trouve dans chooseAlertButton dans apple/runner/AgentDeviceRunner/AgentDeviceRunnerUITests/RunnerTests+Alert.swift, où le repli dismiss renvoie buttons.last. Commencez par la liste d'étiquettes de isDismissButton et la branche dismiss, et comparez-les à la garde déjà présente dans la branche accept. C'est terminé lorsque "Ask App Not to Track" est reconnu comme étiquette de rejet ou lorsque le repli dismiss ne choisit jamais un bouton de type accept, et que l'invite ATT laisse le suivi en denied lors d'une exécution sur simulateur.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Problem
On an iOS simulator, alert dismiss on the App Tracking Transparency prompt (buttons "Ask App Not to Track" and "Allow") taps "Allow". The command prints dismissed and exits 0, but iOS records an authorization, exactly as after alert accept.
Nothing in the output reveals it: a test that dismisses the prompt to decline tracking silently runs the app with tracking authorized.
Environment
- agent-device 0.21.24 (code unchanged in 0.21.27,
0.21.28-nightly.20261014.57andmainat 542fb77, see Cause) - macOS 26.6.2, Xcode 27.0, Node 24.21.0
- Simulator: iPhone 17, iOS 27.0, English locale
- Target app: an Expo development build that calls
requestTrackingAuthorizationon launch
Reproduction
xcrun simctl privacy "$SIM" reset all <bundle id> # ATT status back to notDetermined
npx agent-device open <bundle id> --platform ios --udid "$SIM" --relaunch
npx agent-device alert wait 15000 # "Allow “<app>” to track your activity across other companies’ apps and websites?"
npx agent-device alert dismiss # "dismissed", exit code 0
sqlite3 ~/Library/Developer/CoreSimulator/Devices/"$SIM"/data/Library/TCC/TCC.db \
"select auth_value from access where service='kTCCServiceUserTracking' and client='<bundle id>'"
The development build was opened with --launch-url and its dev-client deep link; any app that requests tracking authorization on launch shows the same prompt. auth_value is 0 when tracking is denied and 2 when it is authorized.
| Response to the prompt | Runs | auth_value |
|---|---|---|
alert dismiss |
4 | 2 (authorized), 4 of 4 |
alert accept |
— | 2 (authorized) |
find text "Ask App Not to Track" click, or click on the button ref |
4 | 0 (denied), 4 of 4 |
Cause
chooseAlertButton in RunnerTests+Alert.swift:
return buttons.first(where: { isDismissButton($0.label) }) ?? buttons.last
"Ask App Not to Track" is not in the isDismissButton list (cancel, close, dismiss, don't allow, not now, no, keep browsing, later), so dismiss falls back to buttons.last, which is "Allow" on this prompt.
The accept branch already guards against the symmetric mistake: when no accept label matches, it only taps a lone button that is not a dismiss button. The dismiss branch has no such guard and can tap a button that isAcceptButton recognizes ("allow").
Suggested fix
Either or both:
- add "ask app not to track" to the dismiss labels;
- in the
dismissfallback, never pick a button thatisAcceptButtonmatches (e.g. the last button that is not an accept button), and fail when every button is an accept button, rather than tap one.
The second keeps dismiss from authorizing on any prompt whose decline label is unknown, including localized ones.
Expected behavior
alert dismiss on the App Tracking Transparency prompt taps "Ask App Not to Track", or fails without tapping, and never records an authorization.
- Langage dominant
- TypeScript
- Étoiles
- 5k
- Forks
- 334
- Merge moyen
- 12 h 29 min
- PR mergées (30 j)
- 663
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de callstack/agent-device
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
callstack/agent-device#1869 ·
Les mainteneurs répondent en général sous 1 jour
-
bug ready-for-agent
Difficulté 4/5 3-5 jours Accessibilité débutants 25/100
callstack/agent-device#3674 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
enhancement ready-for-agent
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 35/100
callstack/agent-device#3531 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 4/5 1-2 jours Accessibilité débutants 55/100
callstack/agent-device#3449 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
bug ready-for-agent
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
callstack/agent-device#3406 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de callstack/agent-device
Issues similaires
-
area:ui effort:S enhancement priority:P2
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 74/100
QuantumNous/new-api#7839 ·
Les mainteneurs répondent en général sous 1 jour
-
good first issue maintenance
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
dark-princezz/stellar-hooks#1010 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
interledger/rhyza#352 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
Les mainteneurs répondent en général sous 1 jour