Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

iOS: the alert-unrecognized warning of `open --launch-url` says to `alert accept`, which grants App Tracking Transparency when that is the alert

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#3,921 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
70/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
ios, typescript
Lĩnh vực
cli, documentation, mobile

Hướng nghiên cứu

Bắt đầu với launchConfirmationUnansweredWarning trong packages/daemon/src/sessions/session-lifecycle/internal/session-open-execution.ts, sau đó kiểm tra các đoạn trợ giúp về open và trong website/docs/docs/commands.md được trích dẫn trong issue. Cập nhật hướng dẫn cho alert-unrecognized để bên gọi kiểm tra cảnh báo và quyết định dựa trên tiêu đề của nó trước khi chấp nhận. Hoàn tất khi cả ba nguồn đều không còn khuyến nghị alert accept cho cảnh báo không được nhận diện; trường kết quả tùy chọn là phạm vi bổ sung.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug ready-for-agent

Summary

On an iOS simulator, open --launch-url recognizes only the English Open in “…”? confirmation with the Cancel and Open buttons. For any other alert, it exits 0 with launchConfirmation: "unanswered", launchConfirmationReason: "alert-unrecognized", and this warning:

iOS shows an alert this open did not recognize (alert-unrecognized), so it left the launch URL unconfirmed. Inspect the current alert with alert get before answering it with alert accept.

agent-device help open gives the same next step: "in both cases inspect the warning and answer with alert get then alert accept". So does commands.md: "Inspect with alert get, then answer with alert accept."

But an alert that open does not recognize is not always the launch confirmation. In our runs, it was the App Tracking Transparency prompt that the app shows at launch (Allow “<app>” to track your activity…). An agent that follows the warning taps Allow, and the simulator's TCC.db records auth_value 2 (allowed) for kTCCServiceUserTracking. The agent gets no signal that it granted a permission, and every later check that depends on the tracking answer is wrong.

Environment

  • agent-device 0.21.29 (measured). The warning, the open help and commands.md are unchanged in 0.21.30, 0.21.31 and on main (b08b5e7).
  • Xcode 27.1, iPhone 17e simulator on iOS 27.0, English locale.
  • Expo development build, with a custom URL scheme that the app owns. The app shows the App Tracking Transparency prompt at launch.
  • The app had already received a deep link on this simulator, so iOS did not show the Open in confirmation. The tracking answer was reset before each run.

Steps

xcrun simctl privacy "$SIM" reset all <bundle-id>
npx agent-device open <bundle-id> --launch-url "<scheme>://..." --platform ios --udid "$SIM" --relaunch --json
npx agent-device alert get --platform ios --udid "$SIM"
npx agent-device alert accept --platform ios --udid "$SIM"   # the step that the warning gives
sqlite3 ~/Library/Developer/CoreSimulator/Devices/"$SIM"/data/Library/TCC/TCC.db \
  "select auth_value from access where service='kTCCServiceUserTracking' and client='<bundle-id>'"

Results

  • open exited 0 with launchConfirmation: "unanswered", launchConfirmationReason: "alert-unrecognized" and the warning above in 9 runs out of 9, 4 of them at the largest Dynamic Type size.
  • alert get returned the title of the App Tracking Transparency prompt.
  • alert accept, as the warning says, recorded auth_value 2 (allowed). alert dismiss recorded 0 (denied).

Cause

answerLaunchConfirmation returns alert-unrecognized for every alert that isLaunchConfirmation rejects. At that point, open does not know whether the alert is a launch confirmation in another language or a different alert. But launchConfirmationUnansweredWarning gives alert accept as the answer in both cases.

The title and the buttons that open read go only to the warn diagnostic ios_launch_confirmation_unanswered. serializeOpenResult does not return them, so a --json caller must run alert get to know which alert it is.

Suggested fix

  1. For alert-unrecognized, do not tell the caller to alert accept. Tell it to read the alert with alert get and to answer it from its title: alert accept only when it is the launch confirmation (for example, a translated Open in prompt). Any other alert, such as a permission prompt, is the app's own alert, and the caller answers it on its own terms. Apply the same change to the open help and to commands.md.
  2. Optionally, return the alert's title and buttons in the open result when the reason is alert-unrecognized (for example, launchConfirmationAlert: { title, buttons }). The caller can then choose its answer without one more alert get.

Expected

The alert-unrecognized warning does not tell the caller to accept an alert that may not be the launch confirmation.

Related

  • #3732 added alert-unrecognized and this warning. It tested the warning only with a translated launch confirmation (French simulator), where alert accept is the correct answer.
  • #3627 / #3715: alert dismiss tapped Allow on the same App Tracking Transparency prompt (fixed).
Ngôn ngữ chính
TypeScript
Star
5.1k
Fork
339
Merge trung bình
11 giờ 54 phút
Pull request đã merge (30 ngày)
745

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của callstack/agent-device

Tất cả issue của callstack/agent-device

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.