From 48083620d5ccdaef02c2f320c2a7fad2431a5360 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Wed, 11 Nov 2026 19:01:44 +0600 Subject: [PATCH] [2026-11-11] eagle: work/projects/cpm-wake-init-detection-tech-design-2026-11-10.md --- work/projects/cpm-wake-init-detection-tech-design-2026-11-10.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/work/projects/cpm-wake-init-detection-tech-design-2026-11-10.md b/work/projects/cpm-wake-init-detection-tech-design-2026-11-10.md index eb7a2427..d645dfe3 100644 --- a/work/projects/cpm-wake-init-detection-tech-design-2026-11-10.md +++ b/work/projects/cpm-wake-init-detection-tech-design-2026-11-10.md @@ -21,7 +21,7 @@ status: draft ## Background & Requirements -Failures after a background wake are the largest group with no fix: on macOS 1.214, 39% of all failures (0.68% of DAU); on iOS 7.244, 22% (0.06% of DAU). The background is ready and a plain idle-unload and wake loses no messages in the real-WebKit harness, so the usual causes are out. +Failures after a background wake are the largest group with no fix: on macOS 1.214, 39% of all failures (0.68% of DAU); on iOS 7.244, 22% (0.06% of DAU). The app cannot see where the startup message stops. For one page: page script sends `init` → background receives it → reads configuration → reads the user setting → checks the site → answers the page and refreshes the app's dashboard. The app sees only the last step, so every failure looks the same: no answer.