[2026-10-20] eagle: work/projects/CPM Breakage Testing Steps.md work/projects/cpm-background-graveyard-experiment-definition.md work/projects/cpm-extension-health-pixels-privacy-triage.md work/projects/cpm-m3-telemetry-privacy-triage.md work/projects/cpm-metrics-causes-and-mitigations-2026-10-16.md work/projects/cpm-pr0-episode-telemetry-summary-2026-10-16.md work/projects/cpm-readiness-telemetry-tech-design-2026-10-15.md work/projects/cpm-service-worker-architecture-and-diagnostics.md work/projects/cpm-telemetry-data-requirements-2026-10-15.md work/projects/cpm-web-extension-breakage-findings.md
This commit is contained in:
Alexey Martemyanov committed
1 parent
5b8f6bc510
commit
8f39ed45d1
17 files changed
+256
-42
No files matched your search
@@ -1,3 +1,70 @@
|
||||
# CPM episode telemetry — testing steps
|
||||
|
||||
Verified against #7376 **`5d1cb4abd2`**, 20 October 2026. These expectations apply to that published branch; the PR is closed without merge. The macOS counterpart #7484 still has the earlier `was_stuck` contract. Full values and limitations: [[cpm-pr0-episode-telemetry-summary-2026-10-16]].
|
||||
|
||||
Use an isolated test profile and filter the Xcode console by `PixelKit` and `CPM Health Monitor`. Finish each episode before starting the next case. In production, the first completed episode per day sends `web_extension_cpm_episode_daily` and `_count` with the same payload; subsequent episodes send count only, across every reason/outcome. PixelKit dry-run logs instead of sending and compresses daily deduplication to two minutes, so a five-minute case may cross that boundary.
|
||||
|
||||
The Debug breakage switch hides native dashboard responses from the detector. It tests monitor/reporting behavior, **not actual loss of page initResp**. A working page can intentionally look broken to the monitor.
|
||||
|
||||
## Healthy navigation
|
||||
|
||||
1. Keep Simulate CPM Messaging Breakage OFF; load an HTTP(S) page with CPM enabled.
|
||||
2. Confirm a normal dashboard response and no episode report after the grace period.
|
||||
3. With simulation ON, visit internal New Tab, Settings or Bookmarks pages: they must not start an eligible HTTP(S) failure measurement.
|
||||
|
||||
## Unconfirmed one-tab failure, then response
|
||||
|
||||
1. Enable simulation; load an HTTP(S) page in one tab.
|
||||
2. Wait for the four-second timeout: an episode opens locally; **no pixel is sent**.
|
||||
3. Disable simulation and reload the same tab before the five-minute deadline.
|
||||
4. On a qualifying response, expect one terminal report: `stuck=false-one`, normally `outcome=failed_tab_response` for the later measurement, `reload_state=none`, bucketed `response_after`.
|
||||
5. No separate init_failed, stuck or recovered event is emitted; the cancelled deadline must not send a second report.
|
||||
|
||||
A late response to the original timed-out measurement is covered by automated tests and yields `failed_measurement_response`; a page reload creates a different measurement.
|
||||
|
||||
## Confirmed persistence: one tab or several
|
||||
|
||||
1. With simulation ON, let tab A time out.
|
||||
2. After that first failure, begin another eligible regular navigation in A and let it time out: persistence becomes true, scope stays one.
|
||||
3. End the episode by a qualifying response after disabling simulation, or leave the app running until the deadline. Expect `stuck=true-one`.
|
||||
4. Repeat with the second qualifying timeout in another tab: expect `stuck=true-many`.
|
||||
5. Automatic extension reload may change `reload_state`; do not assume none. Loaded is not proof that messaging recovered.
|
||||
|
||||
one/many counts distinct tabs with observed timeouts; it does not actively check every tab or determine whether all tabs in one window died.
|
||||
|
||||
## Concurrent failures and session restoration
|
||||
|
||||
1. Start pages in two tabs before either first timeout. Let both time out: scope is many, but those already-in-flight attempts must not confirm persistence.
|
||||
2. Disable simulation and obtain a qualifying response before a further timeout, or wait for the deadline: expect `stuck=false-many`.
|
||||
3. For restoration, use genuinely lazy-restored tabs and verify `session_restoration` in the monitor log. Timeouts in additional restored tabs increase scope but do not confirm persistence.
|
||||
4. A later ordinary navigation started after the first failure can confirm stuck if it times out. `reason` remains the first failure's context.
|
||||
|
||||
## Deadline without another navigation
|
||||
|
||||
1. With simulation ON, cause one eligible timeout.
|
||||
2. Do not open or reload another page; keep the process/monitor alive through five minutes after the first failure.
|
||||
3. Expect `outcome=no_response_before_deadline`, `stuck=false-one`, and **no `response_after`**.
|
||||
4. This is an observation deadline, not proof of permanent failure. Destroying the monitor/process before closure loses the unfinished report.
|
||||
|
||||
## Reload state
|
||||
|
||||
Within an open episode, inspect lifecycle transitions: none → pending → loaded or failed; the first eligible post-reload measurement can set response_timed_out. These transitions do not send separate CPM events. A terminal report carries the observed state. The general web-extension reload-error pixel remains separate. Precise reload/error-generation cases are in `CPMMessagingHealthMonitorTests`.
|
||||
|
||||
## Background history and load attribution
|
||||
|
||||
- All eight booleans and four load fields describe the first failure; a later error must not overwrite them.
|
||||
- Non-stuck episodes have only initial history. Stuck episodes use `initial;events-until-first-stuck`, frozen before its automatic recovery.
|
||||
- Split tokens on commas and semicolons; ignore empty entries and standalone `...`. The marker identifies dropped oldest entries.
|
||||
- The combined value must stay within 12 events and 255 characters, including markers/separators. A long continuation can evict the entire initial phase; no reservation is implemented.
|
||||
- New repeated lifecycle records are retained; only consecutive identical load errors within one second are suppressed.
|
||||
- Missing optional values must be omitted. No URL, document/tab/context ID or PID may be added.
|
||||
|
||||
Deterministic coverage: `testStuckParameterDistinguishesPersistenceAndDistinctFailedTabs`, `testDeadlineReportsQuietEpisodeWithoutAnotherEvent`, `testStuckTimelinePreservesEventsAcrossContextResetAndExcludesRecovery`, `testStuckTimelineMarksOverflowOfTheLiveContinuation` and `CPMMessagingDiagnosticsTests`.
|
||||
|
||||
## Historical checks for the previous separate-pixel contract
|
||||
|
||||
The steps below are retained for the old implementation; their event names and immediate-send expectations **do not apply to #7376**.
|
||||
|
||||
### Testing Steps
|
||||
|
||||
Run each case with fresh app data so daily pixel deduplication does not hide results. In Xcode’s console, filter by `PixelKit` Category.
|
||||
@@ -47,4 +114,3 @@ Run each case with fresh app data so daily pixel deduplication does not hide res
|
||||
- `debug_web_extension_cpm_messaging_extension_reload_failed`
|
||||
4. Navigate again and wait 5 seconds → `debug_web_extension_cpm_messaging_stuck_extension_reload` is sent.
|
||||
5. Select **Simulate CPM Messaging Breakage (Off)** and reload → `debug_web_extension_cpm_messaging_recovered_after_extension_reload` is sent.
|
||||
|
||||
@@ -8,6 +8,12 @@ updated: '2026-09-22'
|
||||
---
|
||||
# CPM Background Graveyard — Experiment Definition
|
||||
|
||||
> **Статус на 20 октября 2026: историческое предложение эксперимента, не текущий план запуска.** `background_graveyard_enabled` удалён из episode report по решению пользователя; сама mitigation не менялась, её local default в проверенном коде OFF. Наличие старой реализации/merged mitigation PR не доказывает активный remote rollout или подтверждённую пользу этого treatment.
|
||||
>
|
||||
> Последняя telemetry implementation — [[cpm-pr0-episode-telemetry-summary-2026-10-16]], #7376 `5d1cb4abd2` (закрыт без merge); результаты и privacy gaps — [[cpm-status-2026-10-15#6. Телеметрия]]. P5/P6 evidence не обосновывает graveyard. Cohort/enrollment/success criteria и «ready» ниже — архив 22 сентября; approval/config/задачи здесь заново не проверялись.
|
||||
|
||||
## История предложения и контекста — сентябрь / 15 октября
|
||||
|
||||
> **Контекст актуализирован 15 октября 2026:** [[cpm-status-2026-10-15]]; архитектурные ограничения — [[cpm-service-worker-architecture-and-diagnostics]]. Определение эксперимента, задачи и readiness ниже сохранены как документ от 22 сентября; их текущий rollout/approval статус этим проходом не переутверждался.
|
||||
>
|
||||
> Новые P5/P6 проверки не являются доказательством пользы graveyard: P5/shared-window теряет tab routing после нормального idle, P6 сохраняет неправильный controller после main-flag cycle. Оба механизма отличаются от terminated-background retention. Для пустых listener metadata естественный production-trigger всё ещё не найден. Полная матрица, scopes и отрицательные контроли — основной статус §10–12. Эксперимент, cohorts, enrollment, metrics и flags этим обновлением не менялись.
|
||||
|
||||
@@ -1,5 +1,11 @@
|
||||
# Privacy Triage: Apple - CPM Extension Health Pixels
|
||||
|
||||
> **Historical privacy draft; current contract checked 20 October 2026.** The separate event list below is superseded on the published #7376 branch by one `web_extension_cpm_episode` with **daily+count**. The PR is closed without merge; no shipping claim follows from this note.
|
||||
>
|
||||
> All current parameters, four-value `stuck`, two-phase `bg_events`, 11 retired events and nine removed fields: [[cpm-pr0-episode-telemetry-summary-2026-10-16]]. Old `platform`/`form_factor` proposals and self-service answers below are not a current approval. No identifiers are added, but rare combinations of fields/history can still be correlated; daily deduplication does not prove anonymity. Approval coverage for the latest field/history changes was not verified. See [[cpm-status-2026-10-15#6. Телеметрия]].
|
||||
|
||||
## Historical context — recorded 15 October 2026
|
||||
|
||||
> **Исторический draft; контекст сверён 15 октября 2026.** Текущая реализация/атрибуция failure, stuck и recovery, PR/CI и новые P5/P6 tests описаны в [[cpm-status-2026-10-15]]. Таблица и поля draft ниже сохранены; это обновление не отправляет privacy review и не утверждает новую схему.
|
||||
>
|
||||
> Actual failure/stuck из новых tests — существующие production monitor events. Healthy page initResp проверяется отдельно от dashboard refresh; source-linked P5/P6 не добавляют новых pixels/params и не доказывают prevalence. См. также [[cpm-m3-telemetry-privacy-triage]] и [[cpm-readiness-telemetry-tech-design-2026-10-15]].
|
||||
@@ -52,7 +58,7 @@ Yes.
|
||||
Yes. They use `platform` and `form_factor` to combine both apps under the same pixel names.
|
||||
|
||||
**Could the parameters link pixels to the same user?**
|
||||
No. Both parameters are coarse enums and contain no identifier.
|
||||
This historical draft proposed only coarse enums. That alone does not establish unlinkability, especially for the current payload containing multiple fields and a lifecycle timeline; combined distinguishability must be reviewed.
|
||||
|
||||
**Do the pixels include a URL or search query?**
|
||||
No. They also exclude hostnames, page titles, tab IDs, document IDs, navigation types, errors, and CPM rules.
|
||||
@@ -70,7 +76,7 @@ To measure how often CPM messaging becomes stuck and whether extension reload re
|
||||
No. They report only CPM extension health states.
|
||||
|
||||
**Can occurrences be tied to the same user or a small group?**
|
||||
No. There is no correlation identifier or browsing data.
|
||||
There is no explicit correlation identifier or browsing data, but rare combinations and matching timeline sequences can still distinguish reports. Daily deduplication is not a guarantee against correlation.
|
||||
|
||||
**Does this meet the self-service criteria?**
|
||||
Yes.
|
||||
This is the historical draft's question, not a current approval. Eligibility/approval for the latest episode fields and timeline changes has not been verified in this documentation update.
|
||||
@@ -1,5 +1,13 @@
|
||||
# TD: Pixel Definition: CPM Failure Diagnostics (macOS/iOS)
|
||||
|
||||
> **Status checked 20 October 2026.** This note preserves the original M3 schema merged in #6844, with later production evidence in iOS 7.240+ / macOS 1.210+. It is not the schema of the current #7376 branch.
|
||||
>
|
||||
> #7376 `5d1cb4abd2` replaces 11 separate CPM events with one terminal `web_extension_cpm_episode`, **daily+count**; it retains eight booleans and bounded `bg_events`, adds the episode/load fields, and drops nine old wire fields including `context_errors` and `network_restarted`. Graveyard treatment attribution is explicitly removed. Exact lists and values: [[cpm-pr0-episode-telemetry-summary-2026-10-16]]. That PR is closed without merge; macOS #7484 is an older contract.
|
||||
>
|
||||
> New `stuck` and `initial;continuation` history/`...` are later changes than the quoted triage's `was_stuck`. Approval of that latest combination was not established here. Sanitization/buckets and absence of IDs do not eliminate combined distinguishability. Current evidence, actual gates and remaining gaps: [[cpm-status-2026-10-15]].
|
||||
|
||||
## Historical context — recorded 15 October 2026
|
||||
|
||||
> **Internal status context — 2026-10-15:** [[cpm-status-2026-10-15]] is the current source for production cohort evidence, PR stack and local reproduction results. The merge/rollout statement below is the historical September 23 record; it must not hide the subsequently collected diagnostic data for iOS 7.240+ and macOS 1.210+.
|
||||
>
|
||||
> Current P5/shared-window and conditional P6/main-flag tests exercise the existing diagnostics; they add no pixel/schema changes. Reproducing a mechanism does not establish its production share, a flag transition, or page delivery from dashboard-only telemetry. Latest readiness proposal and unresolved privacy/review choices are separate: [[cpm-readiness-telemetry-tech-design-2026-10-15]], main status §6–8.
|
||||
|
||||
@@ -8,13 +8,15 @@ tags:
|
||||
---
|
||||
# CPM: metrics, causes and mitigations
|
||||
|
||||
Updated 16 October 2026. Internal metrics; keep these figures out of public PRs. `cpm-e2e-init` is the local test/fix worktree referenced here.
|
||||
Updated 20 October 2026. Internal metrics; keep these figures out of public PRs. Production figures retain their original date windows. `cpm-e2e-init` refers to the historical 16 October test worktree; current PRs and source paths are listed in [[cpm-status-2026-10-15]] and [[cpm-web-extension-code-guide-2026-10-09]].
|
||||
|
||||
## What the metrics mean
|
||||
|
||||
The monitor reports failure when no matching native dashboard refresh arrives within 4 seconds of navigation completion. A second qualifying timeout marks the episode stuck and triggers M4 extension reload. Neither timeout nor recovery proves delivery of `initResp` to the page: tests can receive it while dashboard delivery fails.
|
||||
|
||||
Daily pixels count installation-days per event/reason, not distinct users or episodes. Independently deduplicated failure/recovery totals cannot establish transition or recovery success rates. Keep `.count` separate from `.daily`.
|
||||
The production cut below uses the old separate daily pixels: installation-days per event/reason, not distinct users or paired episodes. Independently deduplicated failure/recovery totals cannot establish transition or recovery success rates. Keep `.count` separate from `.daily`.
|
||||
|
||||
The published #7376 branch changes this to one terminal `web_extension_cpm_episode`, daily+count. Daily counts installations with a completed episode; count counts completed episodes. A new baseline is required. Its current PR is closed without merge, so this is not a shipped-data claim. The four-state `stuck` and two-phase `bg_events` contract is documented in [[cpm-pr0-episode-telemetry-summary-2026-10-16]].
|
||||
|
||||
## Distribution
|
||||
|
||||
@@ -42,23 +44,28 @@ Earlier **5 October post-release** cut: initial failures **6,624 / 1,377**, stuc
|
||||
|
||||
Percentages below are shares of all initial-failure / stuck daily reports in the 12–14 October cut. Snapshot cohorts are proxies for causes; P5/P6 selections use separate denominators.
|
||||
|
||||
- **Network crash:** replacement cohort — **iOS init 16.8%, stuck 39.7%; macOS init 13.6%, stuck 26.6%**. reproduced across tabs/windows; a surviving background view can retain a dead worker after Network-process replacement. Fix B restarts the background. Production attribution remains incomplete: `network_restarted` compares against context load, not the latest view. Add `network_replaced_since_view`; the older analysis supports at most 20–45% of healthy-looking stuck reports, not the whole cohort.
|
||||
- **P1, slow idle wake:** recent-wake cohort — **iOS init 7.9%, stuck 9.5%; macOS init 32.5%, stuck 32.2%**; excludes older wake tails. an imposed startup delay reproduces timeout followed by a late answer; natural production slowness remains unexplained. Local mitigation prepares background before navigation, with a shared, cancellable **5-second maximum wait**. It passed with an 8-second worker delay; longer delays remain possible.
|
||||
- **P2, error 6:** error-6 cohort — **iOS init 6.1%, stuck 21.5%; macOS init 1.0%, stuck 1.9%**. controlled macOS suspension reproduces WebKit's roughly 30-second background-load timeout. The main iOS chains remain unproven. Local mitigation retries `loadBackgroundContent` once on the current context, with cooldown and recovery guards. Same-document dashboard **and page initResp** recovery passed twice. Full-context replacement was rejected after repeat page-response loss. Foreground-resume recovery remains untested.
|
||||
- **P3, loaded context without view:** no-view cohort — **iOS init 48.1%, stuck 10.9%; macOS init 3.3%, stuck 1.8%**. startup dominates on iOS. Base-URL cleanup can delay startup, but the full P3 failure remains unreproduced, including the 20,000-resource cache test. Stable extension base URL is an unfinished candidate.
|
||||
- **P4, first mid-session load:** Fix A signature — **iOS init 3.9%, stuck 0.9%**. Broader recent-load cohort: **iOS init 15.7%, stuck 6.0%; macOS init 20.0%, stuck 6.4%**. early init loss is reproduced; Fix A waits for first background readiness. The narrower signature is 129k → 4.6k iOS reports and can include reloads.
|
||||
- **Network crash:** replacement cohort — **iOS init 16.8%, stuck 39.7%; macOS init 13.6%, stuck 26.6%**. reproduced across tabs/windows; a surviving background view can retain a dead worker after Network-process replacement. [#7459](https://github.com/duckduckgo/apple-browsers/pull/7459) restarts the background and now reports `web_extension_cpm_network_process_recovery_applied` (daily+count, no custom parameters). This counts application, not proven recovery or every crash. Production attribution remains incomplete: `network_restarted` compares against context load, not the latest view. Add `network_replaced_since_view`; the older analysis supports at most 20–45% of healthy-looking stuck reports, not the whole cohort.
|
||||
- **P1, slow idle wake:** recent-wake cohort — **iOS init 7.9%, stuck 9.5%; macOS init 32.5%, stuck 32.2%**; excludes older wake tails. an imposed startup delay reproduces timeout followed by a late answer; natural production slowness remains unexplained. The published #7379 mitigation prepares background before navigation, with a shared, cancellable **5-second maximum wait**. It passed with an 8-second worker delay; longer delays remain possible.
|
||||
- **P2, error 6:** error-6 cohort — **iOS init 6.1%, stuck 21.5%; macOS init 1.0%, stuck 1.9%**. controlled macOS suspension reproduces WebKit's roughly 30-second background-load timeout. The main iOS chains remain unproven. The published #7379 mitigation retries `loadBackgroundContent` once on the current context, with cooldown and recovery guards. Same-document dashboard **and page initResp** recovery passed twice. Full-context replacement was rejected after repeat page-response loss. Foreground-resume recovery remains untested.
|
||||
- **P3, loaded context without view:** no-view cohort — **iOS init 48.1%, stuck 10.9%; macOS init 3.3%, stuck 1.8%**. startup dominates on iOS. Base-URL cleanup can delay startup, but the full P3 failure remains unreproduced, including the 20,000-resource cache test. [#7493](https://github.com/duckduckgo/apple-browsers/pull/7493) now implements a stable private extension origin, default ON with a remote kill switch, excluding installations with web-accessible resources. macOS tests verify origin continuity and removal of repeated migration; they still do not reproduce the complete production P3 failure. No new telemetry definitions are included.
|
||||
- **P4, first mid-session load:** Fix A signature — **iOS init 3.9%, stuck 0.9%**. Broader recent-load cohort: **iOS init 15.7%, stuck 6.0%; macOS init 20.0%, stuck 6.4%**. early init loss is reproduced; #7379 waits for first background readiness and separately counts `web_extension_cpm_startup_response_missing` with daily+count even while late-document reload is disabled. Late-document reload remains default OFF. The narrower signature is 129k → 4.6k iOS reports and can include reloads.
|
||||
- **P5, background fails to wake:** **5 October, after each platform's release tag: iOS init 1.40% (93 / 6,624) → stuck 2.08% (30 / 1,440); macOS init 6.83% (94 / 1,377) → stuck 4.52% (22 / 487)**. Recounted from the saved `cpm-public-attribution-2026-10-06/initialization_daily.tsv` and `events_daily.tsv`: last five `bg_events` names `proxy_on>dealloc>view>proxy_on>dealloc`, excluding error 6, Network replacement and scripts=false. This is the earlier 5 October cut, not 12–14 October. **14 October stuck: iOS 1.15% (1,953 / 169,115); macOS 3.57% (499 / 13,992)**; init for that newer cut has not been recounted. Closing a window with a shared pinned tab reproduces lost tab registration on macOS; fix window/tab lifecycle reporting. That signature appears in **13.6% of macOS P5** (68 / 499), or **0.49% of all macOS stuck**. Missing listener registration also reproduces P5 in controlled tests; its natural trigger remains unknown. The earlier 494-report selection used different filters.
|
||||
- **P6, controller mismatch:** broader detached-tab cohort — **iOS init 0.03%, stuck 0.05%; macOS init 6.2%, stuck 8.9%**. P6-only init/stuck shares are unavailable. a main `webExtensions` flag cycle creates a new manager while existing web views retain the old controller. Recreate/rebind affected views when replacing the manager; context reload alone cannot repair this. The conditional mechanism is reproduced, but its occurrence in production is unconfirmed. Selected macOS tails: **627 + 235** reports.
|
||||
- **Other:** **iOS init 5.3%, stuck 12.5%; macOS init 23.4%, stuck 22.2%**. Tests reproduce slow settings replies, lost messages, and missing dashboard confirmation even when the page receives its answer. Some iOS reports also resemble slow wake-up (P1). Their individual shares are unknown. Mitigations depend on which step fails: wait for background readiness, reduce settings delays, or fix message/confirmation delivery.
|
||||
|
||||
## Open PRs and local validation
|
||||
|
||||
**Last verified open: 15 October, 17:26 UTC. Live GitHub access was declined in this pass; current state is unverified.**
|
||||
Verified from GitHub on 20 October 2026; exact heads and CI failure annotations are in [[cpm-status-2026-10-15#2. PR и quality gates]].
|
||||
|
||||
- [#7376](https://github.com/duckduckgo/apple-browsers/pull/7376): readiness/recovery telemetry; [#7384](https://github.com/duckduckgo/apple-browsers/pull/7384): healthy readiness baselines; [#7385](https://github.com/duckduckgo/apple-browsers/pull/7385) + [extension #3727](https://github.com/duckduckgo/duckduckgo-privacy-extension/pull/3727): native/JS init progress.
|
||||
- [#7378](https://github.com/duckduckgo/apple-browsers/pull/7378): repro harness → [#7379](https://github.com/duckduckgo/apple-browsers/pull/7379): Fix A → [#7381](https://github.com/duckduckgo/apple-browsers/pull/7381): Fix B. Last check: #7384/#7385 failed Danger; #7381 failed Non-Sandbox. B's corrective commit was local only.
|
||||
- The newer [PR0 episode-report proposal](cpm-pr0-episode-telemetry-summary-2026-10-16.md) replaces separate failure/recovery events with one terminal episode report; it supersedes the older reporting design, not the historical measurements.
|
||||
- #7376 `5d1cb4abd2`: **closed without merge**, approved, CI green. macOS #7484 `3fb13b81fe`: open, CI green, but release-base conflict and earlier telemetry contract.
|
||||
- #7379 `674bb809f2`: open on the telemetry branch; **BSK CI failed** on a crashed ConfigurationFetcher XCTest. Earlier green results below belong to their tested revisions.
|
||||
- #7459 `f41c7b7047`: current Network recovery plus applied pixel; open, CI green.
|
||||
- #7493 `dd96018da9`: stable-origin P3 path; open, CI green, full P3 failure still unreproduced.
|
||||
- #7473 `574e9288ae`: shared-pinned window-close P5 fix; open directly on macOS release, CI green. It fixes a subset, not all P5 signatures.
|
||||
- #7378 harness and #7384 baseline are closed without merge. #7385/native progress and extension #3727 remain open; #7385 still depends on the closed baseline branch. Old #7381 is still open but is not the current Network recovery implementation.
|
||||
|
||||
**Local `cpm-e2e-init`, 16 October:** P1/P2 candidates remain uncommitted. **22 unique app methods passed across separate runs**; two deliberate disabled-fix controls failed. Package validation: **806 tests, 14 skipped, zero failures**. Tests use real app/WebKit paths with an instrumented bundle and imposed faults; they do not identify every production cause. P3 remains unreproduced; app P5 establishes one lost navigation. No shipped-effect claim.
|
||||
Readiness timing does not establish message delivery. The episode report still lacks page ACK/last confirmed stage, a final result for initially pending loads, and network replacement relative to its current view. Late errors before stuck can now appear in the history continuation; non-stuck reports keep only their initial history. See [[cpm-status-2026-10-15#6. Телеметрия]].
|
||||
|
||||
**Historical local `cpm-e2e-init`, 16 October:** P1/P2 candidates were uncommitted at that point; the current implementation is in #7379. **22 unique app methods passed across separate runs**; two deliberate disabled-fix controls failed. Package validation: **806 tests, 14 skipped, zero failures**. Tests use real app/WebKit paths with an instrumented bundle and imposed faults; they do not identify every production cause. P3 remains unreproduced; app P5 establishes one lost navigation. No shipped-effect claim.
|
||||
|
||||
Detailed evidence and final validation: [[cpm-status-2026-10-15]] · [[cpm-web-extension-code-guide-2026-10-09]].
|
||||
@@ -8,7 +8,9 @@ tags:
|
||||
---
|
||||
# CPM PR0: one terminal report per failure episode
|
||||
|
||||
**Proposed change:**
|
||||
**Verified 20 October 2026:** [#7376](https://github.com/duckduckgo/apple-browsers/pull/7376), head `5d1cb4abd2`, targets `release/ios/7.243.0`. The implementation is pushed; the PR is **closed without merge**, with APPROVED review and green exact-head CI. This describes that branch, not shipped behavior. [macOS #7484](https://github.com/duckduckgo/apple-browsers/pull/7484) still has the earlier `was_stuck` contract, no two-phase history, and a release-base conflict.
|
||||
|
||||
**Implemented change:**
|
||||
|
||||
Replace separate `init_failed`, `stuck`, `recovery[with/without reload]` and CPM post-reload-failure events with `web_extension_cpm_episode`. Each report contains the initial failure and its observed outcome, so diagnosis no longer requires joining separate failure, stuck and recovery events.
|
||||
|
||||
@@ -28,7 +30,7 @@ Deadline expiry does not prove permanent failure; unfinished episodes can be los
|
||||
|
||||
**Reporting frequency:**
|
||||
|
||||
Both platforms use `daily+count` (`.dailyAndCount`). The first completed episode each day sends `_daily` and `_count` with the same summary; every later completed episode sends `_count` only. Daily deduplication is by event name, across all outcomes. `_daily` estimates affected installations per day; `_count` counts completed episodes.
|
||||
Both platforms use `daily+count` (`.dailyAndCount`). The first completed episode each day sends `_daily` and `_count` with the same summary; every later completed episode sends `_count` only. Daily deduplication is by event name, across all outcomes. `_daily` estimates installations with a completed failure episode that day; `_count` counts completed episodes. These are not distinct people or all affected installations: unfinished episodes can be lost. Old separately deduplicated failure/stuck/recovery totals need a new baseline before comparison.
|
||||
|
||||
|
||||
|
||||
@@ -38,7 +40,7 @@ Both platforms use `daily+count` (`.dailyAndCount`). The first completed episode
|
||||
|
||||
- `reason`: the first timeout's context — `session_restoration`, `tab_crash`, `extension_reload` or `other`. [Previously](https://app.asana.com/1/137249556945/project/481882893211075/task/1218619301158188?focus=true) encoded in failure pixel names.
|
||||
|
||||
- `stuck`: `false-one`, `true-one`, `false-many` or `true-many`. The true/false part says whether a later eligible non-restoration navigation, begun after the first failure, also timed out. The one/many part says whether timeouts were observed in one or multiple distinct tabs during the episode, including concurrent and restoration timeouts. Repeated timeouts in the same tab still count as one. One does not prove other tabs healthy; many does not prove all tabs failed. Tab identifiers stay local.
|
||||
- `stuck`: `false-one`, `true-one`, `false-many` or `true-many`. This replaces the boolean `was_stuck` added in the earlier version of this PR. The true/false part says whether a later eligible non-restoration navigation, begun after the first failure, also timed out. The one/many part says whether timeouts were observed in one or multiple distinct tabs during the episode, including concurrent and restoration timeouts. Repeated timeouts in the same tab still count as one. One does not prove other tabs healthy; many does not prove all tabs failed. Tab identifiers stay local.
|
||||
|
||||
- `outcome`: `failed_measurement_response` for the measurement that timed out; `failed_tab_response` for a later measurement on a failing tab; `other_tab_response` for another tab; `unattributed_response` for an ambiguous current-document match; or `no_response_before_deadline`.
|
||||
|
||||
@@ -63,7 +65,7 @@ These values are captured in the first-failure snapshot and sent in the same ter
|
||||
|
||||
Readiness observation shares the existing `cpmBackgroundDelegateProxy` switch. It calls the public `loadBackgroundContent` API on the next main-queue turn after a new view is created. Disabling observation invalidates pending callbacks; reenabling on an existing view leaves readiness unknown until the next view creation. Error 6 also marks the observed load failed if WebKit never completes its load callback. Later readiness changes and errors do not replace the episode's first-failure snapshot. `pending` means the load was still pending at that snapshot; it may complete or fail later. For example, a snapshot taken 4 seconds after view creation stays `pending` even if error 6 arrives at 30 seconds; that later error does not update the load fields. If observed before stuck confirmation, it appears in the bg_events continuation.
|
||||
|
||||
The added fields' combined distinguishability with the retained `bg_events` still needs checking.
|
||||
The added fields' combined distinguishability with the retained `bg_events` still needs checking. Daily deduplication and the absence of identifiers do not guarantee that rare payloads cannot be correlated. The triage summary quoted in the discussion used `was_stuck`; the current four-value `stuck` and two-phase history must be reflected in the reviewed contract. This documentation update does not establish privacy approval for those later changes.
|
||||
|
||||
`app_state` and `open_tabs` remain deferred to targeted startup/no-view diagnostics; `loading_tabs` is not planned for this change. These additions do not change the four-second detector or add page-side `initResp` acknowledgement.
|
||||
|
||||
@@ -80,7 +82,7 @@ The added fields' combined distinguishability with the retained `bg_events` stil
|
||||
|
||||
|
||||
|
||||
`bg_events` contains the first-failure history and, for confirmed stuck episodes, a `;` followed by events observed afterwards up to that confirmation, before its automatic recovery. Non-stuck episodes keep only the first-failure history. A standalone `...` at the start of either phase means older events were dropped. Both phases share a limit of 12 events and 255 characters, including separators and markers; oldest events are dropped first. Sanitized `token@age` entries retain order and duplicates. Ages use `30s`, `1m`, `2m`, `5m`, `15m` and `over_15`, relative to the first failure before `;` and stuck confirmation after it. An empty phase has no events. Consumers split on both `,` and `;`, ignoring empty entries and standalone `...`. Example: `...,load@1m,view@30s;error_e:6@30s`. No second full diagnostic snapshot is collected.
|
||||
`bg_events` contains the first-failure history and, for confirmed stuck episodes, a `;` followed by events observed afterwards up to that confirmation, before its automatic recovery. Non-stuck episodes keep only the first-failure history. A standalone `...` at the start of either phase means older events were dropped. Both phases share a limit of 12 events and 255 characters, including separators and markers. Oldest initial entries are dropped before continuation entries, so a long continuation can remove the entire initial history. No budget is reserved for either phase; reserving one was discussed but is not implemented. Sanitized `token@age` entries retain order and new repeated events. The initial snapshot is not replayed into the continuation. There is no general deduplication; only consecutive identical load-error notifications within one second are suppressed. Ages use `30s`, `1m`, `2m`, `5m`, `15m` and `over_15`, relative to the first failure before `;` and stuck confirmation after it. An empty phase has no events. Consumers split on both `,` and `;`, ignoring empty entries and standalone `...`. Example: `...,load@1m,view@30s;error_e:6@30s`. No second full diagnostic snapshot is collected.
|
||||
|
||||
|
||||
|
||||
@@ -119,3 +121,13 @@ Standard metadata remains: `appVersion` on both platforms, plus `pixelSource` an
|
||||
|
||||
`context_errors`, `network_restarted`, `critical_memory_age`, `bg_view_creations`, `bg_view_leaked_count`, `app_version_change`, `app_launch_age`, `background_graveyard_enabled` and `recovery_from`. Episode state and response attribution replace `recovery_from`. Graveyard attribution is also removed from the diagnostic model and monitor, including the unused attribution state and methods. The graveyard mitigation itself is unchanged. The retired parameter encoder is removed so only the episode report builds the transmitted payload. App tests added for the dropped open/loading-tab measurements are removed with their project entries.
|
||||
|
||||
**What this still cannot diagnose:**
|
||||
|
||||
A late same-measurement dashboard response without reload helps identify a transient timeout. `stuck=false-*` only means persistence was not confirmed; `true-*` still cannot exclude a working page whose dashboard confirmation was lost. There is no page-side `initResp` ACK or last-confirmed-stage field. One/many measures observed failing tabs, without testing every tab or grouping failures by window.
|
||||
|
||||
The final outcome of an initially pending load is not reported explicitly. Pre-stuck errors can reach the continuation, but successful completion does not update the frozen load fields. Network-replacement attribution relative to the current background view is also missing. The separate `web_extension_cpm_network_process_recovery_applied` in [#7459](https://github.com/duckduckgo/apple-browsers/pull/7459) uses daily+count with no custom parameters; it counts a restart being applied, not all crashes or successful recovery. These follow-up measurements are not part of #7376. Detailed gaps and production truncation evidence: [[cpm-status-2026-10-15#6. Телеметрия]].
|
||||
|
||||
**Validation and lifetime:**
|
||||
|
||||
On `5d1cb4abd2`: 777 WebExtensions tests passed, zero failures; strict SwiftLint passed for all six changed Swift files; both platforms' pixel definitions passed validation. Tests used an isolated package copy with refreshed dependency resolution; the worktree's user-edited lockfile was preserved. All four required CI result checks and Danger are green on this head. The episode pixel is temporary; both definitions list `expires: 2027-01-15`, which does not itself remove runtime code.
|
||||
|
||||
@@ -1,3 +1,25 @@
|
||||
# TD: Pixel Definition: CPM Readiness Telemetry (macOS/iOS)
|
||||
|
||||
## Current implementation — verified 20 October 2026
|
||||
|
||||
The earlier proposal to add parameters to separate failure/recovery pixels has been superseded. The current published #7376 branch (`5d1cb4abd2`) sends **one terminal `web_extension_cpm_episode`, daily+count**, and removes 11 old CPM pixel definitions. The PR is **closed without merge** despite approved review and green exact-head CI; this is not shipped behavior. The macOS counterpart #7484 has the earlier contract and a base conflict.
|
||||
|
||||
The complete current contract, all values, dropped pixels/parameters, frequency and tests are in [[cpm-pr0-episode-telemetry-summary-2026-10-16]]. Use it instead of the historical tables below:
|
||||
|
||||
- A four-second native dashboard timeout opens an in-memory episode; an attributed response or an independent five-minute deadline closes it. The deadline does not require another navigation. Count measures completed episodes; daily is deduplicated across every outcome.
|
||||
- `reason`, four-state `stuck`, `outcome`, `reload_state`, optional `response_after`; four first-failure load fields; eight existing first-failure booleans; bounded `bg_events`. No generic `app_state`, `open_tabs`, `loading_tabs`, `recovery_document` or `recovery_after` is added.
|
||||
- `stuck=false-one/true-one/false-many/true-many` replaces the earlier PR's `was_stuck`. It reports observed timeouts, without testing all tabs or proving their health.
|
||||
- For confirmed stuck episodes, `bg_events` joins the initial history and events until first stuck with `;`; `...` marks dropped oldest entries. One 12-event/255-character budget can evict all initial entries. No per-phase reservation is implemented. Ages are relative to each phase; consumers must support both separators and the marker.
|
||||
- Readiness/error facts remain frozen at first failure. A later pre-stuck error can now reach the timeline; final outcome of an initially pending load is still missing.
|
||||
- No page ACK, last confirmed init stage or `network_replaced_since_view` is present. Extension progress requires both JS and native work; #7385/#3727 are separate unmerged proposals. #7459's separate daily+count applied pixel counts a restart, not every crash or successful recovery.
|
||||
- No identifier, URL or exact timestamp is added. Retained event sequences plus new fields still need combined distinguishability review. The triage summary quoted in the discussion listed `was_stuck`; approval coverage for the later four-state field/history change was not established by this documentation check.
|
||||
|
||||
Current implementation paths and separate fix/harness branches: [[cpm-web-extension-code-guide-2026-10-09#0. Текущая карта worktree и точек входа]]. Current PR/CI states, production truncation evidence and remaining diagnostic gaps: [[cpm-status-2026-10-15]].
|
||||
|
||||
## Historical proposal and validation log — 15–19 October
|
||||
|
||||
The following design, tables, “not requested yet”, OPEN/green states and “current” source claims belong to their recorded dates/revisions. They do not override the implementation above. Test failures, retries and scope limits are preserved.
|
||||
|
||||
> **Актуально — 19 октября 2026, error-6/P4 finding закрыт в опубликованном PR.** [#7379](https://github.com/duckduckgo/apple-browsers/pull/7379) **`8275bcce36`**, база #7376 **`39fe56af4c`**, содержит fix **`fc124938e0`** + 2 штатные регрессии. **201 shared PASS**, strict lint **4 files / 0 violations**. Signed app: **ON 9 PASS → OFF 6 ожидаемых functional FAIL → restored ON 9 PASS**, 0 SKIP, те же бинарники; первый restored attempt **7 PASS / 2 FAIL** (teardown timeout / SIGINT) сохранён, повтор выполнен без изменений и отключения проверок. CI завершён: **43 SUCCESS / 17 SKIPPED**, failures/pending нет. Harness **`6d04496882`** содержит production head и ровно **12 review-only paths**; 38 новых shared regressions относительно базы. Проверенный shipping scope: P1/P2 и независимый P4 detection; late reload остаётся default **OFF**, формы не менялись. Прежние открытые findings ниже — история до fix.
|
||||
|
||||
> **История ревью — 19 октября 2026, до исправления error-6/P4 в `fc124938e0`.** Проверен опубликованный после rebase **`a00dc4afeb`** / база #7376 **`c7adf28e12`**, 7 commits / 22 paths. Остаётся **1 P2: error-6 startup может ошибочно попасть в P4 detection после позднего callback успешного retry**. На текущем head: **196 существующих shared tests PASS + 2 дополнительных probes PASS / 1 новый probe FAIL**. Проверочная однострочная правка только в изолированной копии даёт **199 PASS**; в PR она не внесена. Pixel validators обеих платформ PASS. CI завершён: **53 SUCCESS / 25 SKIPPED**, failures и pending нет; повторный probe подтвердил тот же незакрытый дефект. Предыдущие 197 unit и app 9→6→9 относятся к `fc87237a47`; новая база убрала один retired-telemetry тест. Подробности и границы воспроизведения — в разделе «Полное ревью после P4 detection — error-6 attribution». История ниже сохранена.
|
||||
@@ -26,7 +48,7 @@
|
||||
|
||||
> **Local app validation complete — 16 Oct 2026, 01:48 Bishkek / 15 Oct 19:48 UTC.** Twenty app-hosted methods passed with **0 failures, skips or expected failures** in three invocations of the same signed build: 18 together, P5 separately, persistent cache separately. This validates the requested slow-load, one-navigation/recovery, single-tab, several-tabs/one-window and all-windows diagnostics scenarios. Source-linked app P1/P2/P5/P6 and Network paths are covered; P3 was **not reproduced** with 20,000 cached resources, background SIGKILL self-healed, and app P5 proves one lost navigation plus controls. The earlier red joint run and long P5 attempts remain documented. See [[cpm-status-2026-10-15#Финальный app-hosted итог — 16 октября 2026]] for the full matrix, evidence and limits. No commits, PR changes or telemetry schema changes. PR/CI and production-data statements below retain their original dated provenance.
|
||||
|
||||
# TD: Pixel Definition: CPM Readiness Telemetry (macOS/iOS)
|
||||
|
||||
|
||||
> **Internal documentation update — 2026-10-15, 17:26 UTC.** Current evidence, unresolved review decisions and PR stack: [[cpm-status-2026-10-15]]. This update does not approve or implement the proposed schema changes.
|
||||
>
|
||||
|
||||
@@ -1,5 +1,13 @@
|
||||
# CPM Service Worker — architecture, diagnostics, failure gaps
|
||||
|
||||
> **Current implementation context — 20 October 2026.** The architecture/source audit below remains dated September 25; its bundle versions, milestones and open-source bug shipping statements are historical. Current sources/worktrees: [[cpm-web-extension-code-guide-2026-10-09#0. Текущая карта worktree и точек входа]].
|
||||
>
|
||||
> #7376 now has one terminal episode report, daily+count, four-state `stuck` and two-phase bounded `bg_events`; it is published but closed without merge. #7459 adds an applied Network-recovery pixel, not a success ACK; #7493 implements the restricted stable-origin P3 policy and verifies migration controls without reproducing the full P3 failure. #7473 fixes the shared-pinned window-close mechanism. Older “no fix / not implemented” claims below describe earlier revisions.
|
||||
>
|
||||
> An answered native dashboard does not prove page `initResp` delivery; a responsive process/loaded background does not prove a working worker/message route. Page ACK/stage attribution, final pending-load outcome and per-view Network attribution remain missing. Updated telemetry and privacy limits: [[cpm-status-2026-10-15#6. Телеметрия]].
|
||||
|
||||
## Historical context — recorded 15 October 2026
|
||||
|
||||
> **Follow-up evidence — 2026-10-15.** Current status, test outcomes and scope: [[cpm-status-2026-10-15]] (§10–12); current worktree map: [[cpm-web-extension-code-guide-2026-10-09]] (§0). The source audit below remains the September 25 baseline; its bundle version and worktree/milestone readiness are historical.
|
||||
>
|
||||
> - The October harness uses bundled extension **2026.9.29**, real production manager/coordinator/monitor/recorder/native handler and system WebKit on macOS 26.7.1. A temporary extracted bundle copy carries trace and DOM initResp marks; the production zip is unchanged. It does not run the entire browser app/AppKit.
|
||||
|
||||
@@ -6,10 +6,12 @@ tags:
|
||||
- cpm
|
||||
- telemetry
|
||||
---
|
||||
|
||||
# Перенесено
|
||||
|
||||
Содержимое этой заметки (требования к телеметрии из гипотез, когорты ClickHouse, паттерны событий, список невоспроизведённых картин, анализ `bg_events`, SQL) сведено в единый документ со статусом: [[cpm-status-2026-10-15]].
|
||||
Требования к телеметрии, когорты ClickHouse, паттерны событий, невоспроизведённые картины, `bg_events` и SQL сведены в [[cpm-status-2026-10-15]].
|
||||
|
||||
**Актуализировано 20 октября 2026.** Начинать с §1–2 (реальные PR/CI), §6 (диагностическое покрытие и privacy), §7–8 (критерии и незакрытые вопросы). Полный состав опубликованного #7376 — [[cpm-pr0-episode-telemetry-summary-2026-10-16]]; код/worktree — [[cpm-web-extension-code-guide-2026-10-09#0. Текущая карта worktree и точек входа]].
|
||||
|
||||
Актуальный статус на 15 октября после исследования P5/P6: в основном документе §1–9 — сводка PR/CI/данных/решений, §10–11 — полная хронология, §12 — все 14 текущих test results, positive/negative controls, ограничения, исходники, команды и логи. Карта всех CPM worktree и suites актуализирована в [[cpm-web-extension-code-guide-2026-10-09]] (§0). Source-linked P5/tab=false подтверждён; P6 main-flag path условный, occurrence в production не установлен.
|
||||
#7376 закрыт без merge; macOS counterpart отстаёт. В реализованном контракте есть four-state `stuck`, два этапа `bg_events` с `;`/`...`, daily+count. Нет page ACK/последнего подтверждённого этапа, final outcome изначально pending load или `network_replaced_since_view`. Резерв бюджета для initial history обсуждён, но не реализован. Applied pixel #7459 считает применение Network recovery, не доказанный успех.
|
||||
|
||||
Исторические app/SPM проверки, включая красные и отрицательные результаты, сохранены в основном документе с датами и heads. Они не доказывают причину каждого production failure или актуальную готовность к релизу.
|
||||
@@ -10,6 +10,14 @@ tags:
|
||||
---
|
||||
# CPM Web Extension Breakage Findings
|
||||
|
||||
> **Актуальный контекст — 20 октября 2026.** Это исторический журнал source audit, ручных repro и отозванных гипотез. Его «нет фикса», local-only, bundle/OS и CI states относятся к датам записей; текущие heads и gates — [[cpm-status-2026-10-15#2. PR и quality gates]].
|
||||
>
|
||||
> Опубликованы отдельные реализации P1/P2/P4 (#7379), Network recovery (#7459), P3 stable origin (#7493) и shared-pinned P5 (#7473); это не доказательство shipped effect или всей production causal share. #7376 с единым episode report закрыт без merge. Его `bg_events` теперь продолжается до первого stuck, имеет `;`/`...`, но общий budget может вытеснить initial history. Реальная потеря начала подтверждена агрегатами production (§6 основного статуса).
|
||||
>
|
||||
> Page ACK отсутствует; потеря native dashboard при работающей странице остаётся возможным false positive. P5/tab=true, natural listener metadata loss, iOS lifecycle и occurrence P6 transitions всё ещё не установлены. Исходные красные/положительные/отрицательные результаты ниже сохранены.
|
||||
|
||||
## Историческая сводка — 15 октября 2026
|
||||
|
||||
> **Текущий статус — 15 октября 2026:** [[cpm-status-2026-10-15]] (§1–5, §10–12); текущая карта файлов/worktree — [[cpm-web-extension-code-guide-2026-10-09]] (§0). Следующие сентябрьские выводы, ручные проверки и отозванные гипотезы сохранены как история, а не новый verdict.
|
||||
>
|
||||
> - Shared pinned window close, вручную наблюдавшийся 10 сентября ниже, теперь воспроизведён автоматическим SPM-тестом на system WebKit/macOS 26.7.1. Текущие browser source и tag `1.210.0+macos` уже фильтруют сохраняемые tabs перед **явными** didCloseTab, но последующий didCloseWindow всё ещё заставляет WebKit закрыть каждый tab из delegate tabs(for:). Получен P5: два failure → stuck, view=false, tab=false, controller/scripts=true, errors=none, network_restarted=false. AppKit целиком тестом не загружался; browser call chain прочитан, shared production listener и WebKit исполнялись.
|
||||
|
||||
@@ -1,5 +1,13 @@
|
||||
# CPM Web Extension breakage — полное summary сессии
|
||||
|
||||
> **Контекст актуализирован 20 октября 2026.** Это summary исследований 7–9 октября с follow-up от 15 октября, а не текущий PR contract. Последние states/CI и implementations — [[cpm-status-2026-10-15]], код — [[cpm-web-extension-code-guide-2026-10-09#0. Текущая карта worktree и точек входа]].
|
||||
>
|
||||
> #7376 реализован как один terminal episode report, daily+count; PR закрыт без merge. Текущие `stuck`, двухфазный `bg_events`, удалённые события/поля и ограничения — [[cpm-pr0-episode-telemetry-summary-2026-10-16]]. Старые daily event ratios не являются переходами одного пользователя; новый baseline нужен отдельно.
|
||||
>
|
||||
> Source-linked P5/shared-window и условный P6 подтверждены; дальнейшие app/fix проверки датированы в основном статусе. Page ACK по-прежнему нет, а новые данные не объясняют весь Others. Production truncation evidence и оставшиеся измерения — §6.
|
||||
|
||||
## Историческое продолжение — 15 октября 2026
|
||||
|
||||
> **Текущее продолжение — 15 октября 2026:** [[cpm-status-2026-10-15]]; актуальная карта worktree — [[cpm-web-extension-code-guide-2026-10-09]] (§0). Разделы 1–9 ниже относятся к 7 октября, §10 — к 9 октября; они не являются последним статусом.
|
||||
>
|
||||
> Добавлены 14 P5/P6 tests, все текущие методы имеют green в раздельных запусках. Найдены и проверены пути browser window-close → WebKit forgetTab → P5/tab=false и условный main-feature-flag handler cycle → replacement controller → P6. Для P5/tab=true, естественной потери metadata, actual iOS suspend/resume и production main-flag transitions доказательств нет. Полный AppKit flow не запускался; browser source contract прочитан, production shared classes и system WebKit исполнены.
|
||||
|
||||
@@ -1,8 +1,16 @@
|
||||
# CPM Web Extension Breakage — статус и проверка причин
|
||||
|
||||
> **Сверено 20 октября 2026.** Актуальный реестр PR/CI — [[cpm-status-2026-10-15#2. PR и quality gates]], телеметрия/границы диагностики — §6, исходники — [[cpm-web-extension-code-guide-2026-10-09#0. Текущая карта worktree и точек входа]].
|
||||
>
|
||||
> #7376 `5d1cb4abd2` опубликован, CI зелёный, но закрыт без merge. #7484 — старый macOS payload с conflict. #7379 имеет failed BSK crash gate; #7459, #7493 и #7473 имеют зелёный exact-head CI. Новая телеметрия измеряет completed episodes, не совпадает со старой системой event totals.
|
||||
>
|
||||
> Таблицы M2/M5/M6, «Network restart отвергнут», «всё local» и старые OPEN/CI ниже — датированная история. P3 stable-origin policy теперь в #7493, Network fix — #7459 с отдельным applied pixel; это не полная causal attribution или доказанный production recovery rate.
|
||||
|
||||
## Исторический контекст — 15 октября 2026
|
||||
|
||||
> **Актуализировано 15 октября 2026.** Текущий реестр PR/CI, данные 12–14 октября, исходы и ограничения всех новых P5/P6 tests — [[cpm-status-2026-10-15]]. Worktree/команды — [[cpm-web-extension-code-guide-2026-10-09]] (§0). Таблицы milestones, готовность M2/M5/M6 и «Network restart отвергнут» ниже — исторические оценки сентября; они не являются текущим статусом.
|
||||
|
||||
## Текущая проверка — 15 октября
|
||||
## Историческая проверка — 15 октября
|
||||
|
||||
- P5/tab=false: source-linked shared-pinned window close → WebKit внутренний didCloseTab → tab-not-found до wake. Exact stuck-сигнатура воспроизведена; unrelated-window control здоров. Только browser contract + shared classes/system WebKit, не полный AppKit E2E.
|
||||
- P6: main flag true→false→true через production handler воспроизводит wrong-controller/no-scripts; факт переключения в production не установлен. nil-controller варианты остаются controlled. Обычный startup с correct controller здоров, embedded-only cycle сохраняет controller.
|
||||
|
||||
@@ -6,6 +6,28 @@ tags:
|
||||
- cpm
|
||||
- webkit
|
||||
---
|
||||
# CPM Web Extension — карта кода по worktree и строкам
|
||||
|
||||
**Проверено 20 октября 2026:** карта ниже отражает существующие worktree и опубликованные heads; старые line numbers и результаты в архивных разделах относятся к своим ревизиям. PR/CI — [[cpm-status-2026-10-15#2. PR и quality gates]]. Пользовательский dirty `Package.resolved` в telemetry worktree сохранён.
|
||||
|
||||
## 0. Текущая карта worktree и точек входа
|
||||
|
||||
Все пути относительно `/Users/admin/DuckDuckGo/apple-browsers.git/`.
|
||||
|
||||
- **Episode telemetry:** `alex/cpm-telemetry-pr0`, ветка `alex/cpm-messaging-readiness-telemetry`, head **`5d1cb4abd2`**, #7376. PR закрыт без merge, CI зелёный. Начинать с [report/payload](/Users/admin/DuckDuckGo/apple-browsers.git/alex/cpm-telemetry-pr0/SharedPackages/WebExtensions/Sources/WebExtensions/Pixels/WebExtensionPixelFiring.swift), затем [monitor](/Users/admin/DuckDuckGo/apple-browsers.git/alex/cpm-telemetry-pr0/SharedPackages/WebExtensions/Sources/WebExtensions/Autoconsent/CPMMessagingHealthMonitor.swift), [diagnostics/encoder](/Users/admin/DuckDuckGo/apple-browsers.git/alex/cpm-telemetry-pr0/SharedPackages/WebExtensions/Sources/WebExtensions/Autoconsent/CPMMessagingDiagnostics.swift), [recorder](/Users/admin/DuckDuckGo/apple-browsers.git/alex/cpm-telemetry-pr0/SharedPackages/WebExtensions/Sources/WebExtensions/Autoconsent/CPMMessagingDiagnosticsRecorder.swift) и [readiness observer](/Users/admin/DuckDuckGo/apple-browsers.git/alex/cpm-telemetry-pr0/SharedPackages/WebExtensions/Sources/WebExtensions/Autoconsent/CPMBackgroundReadinessObserver.swift). Полный contract — [[cpm-pr0-episode-telemetry-summary-2026-10-16]].
|
||||
- Тесты episode/state transitions: `SharedPackages/WebExtensions/Tests/WebExtensionsTests/CPMMessagingHealthMonitorTests.swift`; payload/timeline — соответствующие Diagnostics/Recorder tests в том же каталоге. Definitions и dictionaries — обе платформы, `{iOS,macOS}/PixelDefinitions/pixels/`. Новый `stuck` — четыре значения; `bg_events` — `initial;until-first-stuck`, общие 12 events/255 chars, `...` означает усечение. Initial phase не имеет зарезервированного бюджета.
|
||||
- **macOS telemetry:** `alex/cpm-telemetry-macos-release`, ветка `alex/cpm-messaging-readiness-telemetry-macos-release`, **`3fb13b81fe`**, #7484. Старый `was_stuck`, без двухфазного timeline; release-base conflict. Это не идентичная копия текущего #7376.
|
||||
- **P1/P2/P4:** `alex/cpm-fix-init-loss-production`, `alex/cpm-fix-init-loss`, **`674bb809f2`**, #7379 на telemetry branch. Главные точки — `Manager/WebExtensionManager.swift`, `Autoconsent/CPMBackgroundReadinessRecovery.swift` и `Pixels/WebExtensionPixelFiring.swift` внутри WebExtensions Sources. Independent `startup_response_missing` не зависит от default-OFF late reload; recovery outcomes не являются page ACK. CI BSK красный. Отдельный app harness — `alex/cpm-fix-p1-p2`, `codex/cpm-fix-init-loss-integration-tests`.
|
||||
- **Network recovery:** `alex/cpm-network-process-recovery`, **`f41c7b7047`**, #7459 на telemetry branch; [watch/restart](/Users/admin/DuckDuckGo/apple-browsers.git/alex/cpm-network-process-recovery/SharedPackages/WebExtensions/Sources/WebExtensions/Lifecycle/CPMNetworkProcessRecovery.swift), manager wiring и `CPMNetworkProcessRecoveryTests.swift`. Applied pixel в metadata/обоих definitions: daily+count, no custom params, только после принятого restart. Нет доказательства recovery и нет `network_replaced_since_view` в episode. Harness: `alex/cpm-network-process-integration-tests`, `codex/cpm-network-process-integration-tests`.
|
||||
- **P3 stable origin:** `alex/cpm-p3-stable-base-url`, **`dd96018da9`**, #7493 на telemetry branch; production default ON, remote kill switch. Это уже опубликованный ограниченный CPM origin policy, не старый глобальный M2 prototype. Harness `alex/cpm-p3-integration-tests`, `codex/cpm-p3-integration-tests`; full P3 failure остаётся невоспроизведённым.
|
||||
- **P5 shared pinned close:** `alex/cpm-p5-pinned-window-close`, **`574e9288ae`**, #7473 на `release/macos/1.213.0`, CI зелёный; harness `alex/cpm-p5-integration-tests`, `codex/cpm-p5-release-integration-tests`. Один доказанный tab-lifecycle mechanism.
|
||||
- **Большой rewrite:** `alex/cpm-episode-telemetry`, **`7e8128c94f`** — альтернативный prototype, **не** реализация #7376. Не читать `CPMEpisodeTelemetry.swift`/`CPMEpisodeSummary.swift` как текущий PR.
|
||||
- Старый самостоятельный harness #7378 и baseline #7384 закрыты без merge. Native progress #7385 и JS #3727 открыты и не встроены в #7376; end-to-end delivery требует обеих сторон и обновлённого extension bundle.
|
||||
|
||||
Для ручной проверки именно terminal-report contract — [[CPM Breakage Testing Steps]]. Прежние commands/counts/line mappings ниже сохранены как история, а не инструкции для текущего head.
|
||||
|
||||
## Архив кратких обновлений — 16–19 октября
|
||||
|
||||
> **Актуально — 19 октября 2026, error-6/P4 finding закрыт в опубликованном PR.** [#7379](https://github.com/duckduckgo/apple-browsers/pull/7379) **`8275bcce36`**, база #7376 **`39fe56af4c`**, содержит fix **`fc124938e0`** + 2 штатные регрессии. **201 shared PASS**, strict lint **4 files / 0 violations**. Signed app: **ON 9 PASS → OFF 6 ожидаемых functional FAIL → restored ON 9 PASS**, 0 SKIP, те же бинарники; первый restored attempt **7 PASS / 2 FAIL** (teardown timeout / SIGINT) сохранён, повтор выполнен без изменений и отключения проверок. CI завершён: **43 SUCCESS / 17 SKIPPED**, failures/pending нет. Harness **`6d04496882`** содержит production head и ровно **12 review-only paths**; 38 новых shared regressions относительно базы. Проверенный shipping scope: P1/P2 и независимый P4 detection; late reload остаётся default **OFF**, формы не менялись. Прежние открытые findings ниже — история до fix.
|
||||
|
||||
> **История ревью — 19 октября 2026, до исправления error-6/P4 в `fc124938e0`.** Проверен опубликованный после rebase **`a00dc4afeb`** / база #7376 **`c7adf28e12`**, 7 commits / 22 paths. Остаётся **1 P2: error-6 startup может ошибочно попасть в P4 detection после позднего callback успешного retry**. На текущем head: **196 существующих shared tests PASS + 2 дополнительных probes PASS / 1 новый probe FAIL**. Проверочная однострочная правка только в изолированной копии даёт **199 PASS**; в PR она не внесена. Pixel validators обеих платформ PASS. CI завершён: **53 SUCCESS / 25 SKIPPED**, failures и pending нет; повторный probe подтвердил тот же незакрытый дефект. Предыдущие 197 unit и app 9→6→9 относятся к `fc87237a47`; новая база убрала один retired-telemetry тест. Подробности и границы воспроизведения — в разделе «Полное ревью после P4 detection — error-6 attribution». История ниже сохранена.
|
||||
@@ -27,11 +49,10 @@ tags:
|
||||
> **App integration update — 16 октября 2026, 01:48 Бишкек.** В `cpm-e2e-init` добавлены 20 методов настоящего app-hosted CPM suite: финальные **20/20 PASS, 0 failures/skips/expected failures**, группы 18+1+1 на одной signed build. Схема `CPM Integration Tests`; файлы/guards/запуск/ограничения — §5 ниже, полный реестр и история — [[cpm-status-2026-10-15#Финальный app-hosted итог — 16 октября 2026]]. Без commits. Карта остальных worktree/PR ниже сохраняет свою датированную сверку 15 октября.
|
||||
|
||||
|
||||
# CPM Web Extension — карта кода по worktree и строкам
|
||||
|
||||
> **Актуальная карта — 15 октября 2026.** Текущий статус PR/CI, данные и все 14 новых P5/P6 результатов: [[cpm-status-2026-10-15]] (§2, §5, §10–12). Датированные исходные разделы 1–4 ниже сохранены; их «ничего не закоммичено», номера строк и общий worktree описывают 9 октября, а не текущее состояние.
|
||||
|
||||
## 0. Текущая карта worktree и запусков
|
||||
## Историческая карта worktree и запусков — 15–19 октября
|
||||
|
||||
Корень: `/Users/admin/DuckDuckGo/apple-browsers.git/`. Проверены `git worktree list`, HEAD и наличие тестовых файлов. **Единого worktree со всеми suites нет.** Общая база в истории не включает local dirty/untracked файлы; особенно это относится к remaining-failures и scratch init-progress E2E.
|
||||
|
||||
|
||||
@@ -10,6 +10,14 @@ tags:
|
||||
|
||||
# CPM Web Extension failures: what the data shows
|
||||
|
||||
> **Current context — checked 20 October 2026.** This analysis retains its October 5 production cut and October 8 conclusions; newer 12–14 October cohorts and truncation evidence have separate denominators in [[cpm-status-2026-10-15]]. They are not joined user transitions or causal shares.
|
||||
>
|
||||
> The original phase-1 schema below has been superseded by one terminal `web_extension_cpm_episode`, daily+count, on #7376 `5d1cb4abd2`; that PR is closed without merge. Actual fields, removals and observation limits: [[cpm-pr0-episode-telemetry-summary-2026-10-16]]. P1/P2/P4, Network, stable-origin P3 and shared-pinned P5 implementations now have separate PRs; their gates are in the main status.
|
||||
>
|
||||
> Ready background + no native answer does not prove a lost init message. Page `initResp` may arrive while dashboard delivery fails, even in a detector-stuck episode. Neither timing fields nor `bg_events` provide end-to-end delivery proof. WebKit issue states and OS shipping statements below are the historical source audit, not freshly verified release information.
|
||||
|
||||
## Historical context — recorded 15 October 2026
|
||||
|
||||
> **Current status — 2026-10-15:** [[cpm-status-2026-10-15]] (§3–5, §10–12). The October 8 data and denominators below are retained; use the main status for the October 12–14 cohort snapshot and the October 14 P5/P6 selection. These are different cuts, not interchangeable totals.
|
||||
>
|
||||
> New causal evidence is narrower than a whole production cohort: shared-window closure reproduces P5/tab=false through production listener + system WebKit; a main-flag cycle through the real handler reproduces P6, but actual production flag changes remain unproven. This does not retract the earlier observation that the normal remote flag was stable. P5/tab=true, natural listener metadata loss and real iOS lifecycle are still unexplained.
|
||||
@@ -36,10 +44,10 @@ Important: a failure pixel means "no answer within 4 seconds". It does not mean
|
||||
|
||||
## Key findings
|
||||
|
||||
1. **Most failures happen right after WebKit wakes the background worker** following idle unload, while the app-side state looks healthy. A test reproduces this exact pattern when the worker takes longer than 4 seconds to start. Many of these failures are late answers rather than lost ones.
|
||||
2. **About a third of iOS "stuck" reports carry WebKit error 6, "background failed to load".** The root cause is in WebKit: the 30-second idle-unload timer starts before the background has finished loading. A load slower than 30 seconds is cancelled.
|
||||
3. **A crash of WebKit's networking process explains only a minority (20–45%) of the cases that look healthy.** It is the only cause we found that breaks every tab at once, including pages that were already open.
|
||||
4. **Phase 1 telemetry, ready but not shipped, separates "slow start" from "lost message" and "late answer" from "no answer".** It should ship before or together with any fix, so the effect of fixes can be measured.
|
||||
1. **Recent wake is common among healthy-looking failures.** A worker start longer than four seconds reproduces a timeout with an otherwise healthy app-side snapshot. This establishes a possible mechanism, not the cause or recovery outcome of each production report.
|
||||
2. **About a third of iOS "stuck" reports in this historical cut carry WebKit error 6, "background failed to load".** Source analysis and controlled macOS suspension show that WebKit's roughly 30-second timer can cancel an unfinished background load. The natural cause of every iOS error-6 report was not established.
|
||||
3. **Network-process replacement is present in a minority (20–45%) of healthy-looking reports under these selections.** A crash can reproduce failures across existing and new tabs. Replacement since context load is a proxy, not proof that this mechanism caused each selected failure or that every tab failed in production.
|
||||
4. **The new episode telemetry adds load evidence and native-response attribution.** It can distinguish an observed late response from no response within the window, but cannot prove page delivery or identify every lost-message cause. The original phase-1 proposal below is historical; the current contract is linked above.
|
||||
|
||||
## Data used
|
||||
|
||||
@@ -68,19 +76,19 @@ Important: a failure pixel means "no answer within 4 seconds". It does not mean
|
||||
- Memory pressure and WebKit errors are almost never present.
|
||||
- Both macOS 26.7 and 27.0 are affected. The iOS version split has not been checked yet.
|
||||
|
||||
**How often failures recover:**
|
||||
- After a single failure, answers resume without a reload on about a quarter of install-days (23% iOS, 25% macOS). The same devices recover repeatedly, about twice a day on iOS.
|
||||
- After a "stuck" episode and the extension reload, answers resume on 64% of iOS and 74% of macOS install-days.
|
||||
**Ratios of separately deduplicated daily event totals:**
|
||||
- Recovery-without-reload daily totals are about 23% of initial-failure totals on iOS and 25% on macOS. The iOS count/daily ratio is about two reports per reporting installation-day; it does not identify repeated activity by the same people.
|
||||
- Recovery-after-reload daily totals are 64% of stuck daily totals on iOS and 74% on macOS. These independently deduplicated counts do not establish an episode recovery probability.
|
||||
- The recovery pixels cannot yet tell a late answer from a later page that worked. Phase 1 telemetry adds this.
|
||||
|
||||
**Single failures and stuck episodes have different patterns:**
|
||||
- Failures right after an extension load make up 32% of single failures but only 18% of stuck reports.
|
||||
- Failures right after a wake-up make up 44% of single failures but 61% of stuck reports.
|
||||
- So failures after a load usually clear on their own, while failures after a wake-up more often turn into "stuck".
|
||||
- Recent-load and recent-wake signatures have different shares in the two separately sampled event populations. This does not show which individual initial failures later became stuck or recovered.
|
||||
|
||||
## Theories and their status
|
||||
|
||||
- **Networking process crash leaves the background worker dead.** Reproduced in tests. Explains at most 20–45% of healthy-looking stuck reports. App fix written, not merged.
|
||||
- **Networking process crash leaves the background worker dead.** Reproduced in tests. Its replacement signature appears in 20–45% under these filters; the causal share is unknown. The current app fix is #7459, not merged.
|
||||
- **The first message is lost when a new extension version loads.** Reproduced in tests. At launch the app already waits for the extension, so this is covered. Installing or updating the extension mid-session was not covered; app fix written, not merged.
|
||||
- **The background worker dies while the networking process stays alive.** Reproduced in tests. The app cannot detect it directly, so it can only react after the first failure.
|
||||
- **Error 6.** The cause was found in WebKit source code and reproduced on macOS. It did not reproduce on an iPhone with iOS 26.7.1 in four scenarios. Telemetry has been added to tell which conditions trigger it.
|
||||
@@ -117,7 +125,7 @@ Important: a failure pixel means "no answer within 4 seconds". It does not mean
|
||||
1. after a networking process crash, WebKit does not notice that the background worker is dead;
|
||||
2. the idle-unload timer starts before the background finishes loading, which causes error 6.
|
||||
|
||||
## Telemetry added (phase 1, not shipped yet)
|
||||
## Historical phase-1 proposal — superseded by the episode report
|
||||
|
||||
All values are coarse buckets or fixed labels, with no URLs or identifiers.
|
||||
|
||||
@@ -132,7 +140,7 @@ All values are coarse buckets or fixed labels, with no URLs or identifiers.
|
||||
- how long after the first failure answers resumed (`recovery_after`).
|
||||
|
||||
**How to read it:**
|
||||
- "Background not ready" together with "created a few seconds ago" means a slow wake-up.
|
||||
- "Background ready" with no answer means a lost message.
|
||||
- A recovery on the failed page means the answer was late, not lost.
|
||||
- An error 6 about 30 seconds after the background was created points at WebKit's unload timer.
|
||||
- "Background not ready" with a newly created view identifies an unfinished load/wake at that snapshot; it does not prove why it is slow or how it will end.
|
||||
- "Background ready" with no native answer still permits several causes: init loss, settings delay, lost page response, or lost dashboard confirmation.
|
||||
- A dashboard response attributed to the same timed-out measurement proves a late native confirmation. A later navigation in the same tab does not prove that the original page received its initResp.
|
||||
- Error 6 about 30 seconds after view creation is consistent with the WebKit timer mechanism; it does not establish the natural trigger of every production error.
|
||||
@@ -1,5 +1,13 @@
|
||||
# CPM Web Extension: attribution и сравнение релизов — 5 октября 2026
|
||||
|
||||
> **Исторический отчёт за 5 октября; контекст сверён 20 октября 2026.** Таблицы, release-tag cutoffs и контрольные суммы сохранены без пересчёта. Актуальные PR/CI, отдельные когорты 12–14 октября и проверка обрезания history за 14 октября — [[cpm-status-2026-10-15]]. Новые числа нельзя переносить в прежние знаменатели.
|
||||
>
|
||||
> #7376 заменяет раздельные события terminal episode report (daily+count), four-state `stuck` и `initial;pre-stuck` timeline с `...`; PR закрыт без merge. Старый parser и параметры этой заметки не являются текущим wire contract. См. [[cpm-pr0-episode-telemetry-summary-2026-10-16]]. Совпадающие `bg_events` и ratios независимо deduplicated daily events не доказывают пару одного пользователя или recovery success.
|
||||
>
|
||||
> Shared-pinned window-close fix теперь в #7473; per-view Network recovery — #7459 с applied pixel, stable-origin P3 — #7493. Их наличие не превращает прежние snapshot cohorts в доказанные causal shares.
|
||||
|
||||
## Историческое дополнение — 15 октября 2026
|
||||
|
||||
> **Исторический отчёт за 5 октября; контекст обновлён 15 октября.** Таблицы, release-tag cutoffs и контрольные суммы этого дня сохранены без пересчёта. Текущие когорты 12–14 октября, PR/CI и P5/P6 tests — [[cpm-status-2026-10-15]]; переносить новые числа в прежние знаменатели нельзя.
|
||||
>
|
||||
> Дополнительная проверка показала: фильтр сохранённых tabs перед явным didCloseTab уже присутствует в release 1.210, однако последующий didCloseWindow заставляет WebKit снова закрыть shared pinned tabs, которые возвращает delegate. Этот путь воспроизвёл P5/tab=false; наличие исходного M1 fix не доказывает устранение всего window-close контракта. Условный main-flag cycle воспроизводит P6, но его occurrence в этом или более позднем production-срезе не доказан. Полная область объяснения и контроли — основной статус §11–12.
|
||||
|
||||
@@ -10,6 +10,14 @@ tags:
|
||||
|
||||
# CPM Web Extension — воспроизведение и фикс
|
||||
|
||||
> **Актуализировано 20 октября 2026.** Этот документ сохраняет последовательность исследования и старый A/B/phase-1 design 8–9 октября. «Ничего не закоммичено», общая ready-handshake branch и line/test counts ниже относятся к своим датам.
|
||||
>
|
||||
> Текущие implementations: #7379 P1/P2/P4; #7459 Network recovery с applied daily+count; #7493 ограниченный stable-origin P3 policy; #7473 shared-pinned window close. Heads, bases и CI — [[cpm-status-2026-10-15#2. PR и quality gates]], worktrees — [[cpm-web-extension-code-guide-2026-10-09#0. Текущая карта worktree и точек входа]].
|
||||
>
|
||||
> #7376 уже переработан в один terminal episode report: four-state `stuck`, двухфазный bounded `bg_events`, daily+count. Он закрыт без merge; macOS counterpart отстаёт. Полный контракт — [[cpm-pr0-episode-telemetry-summary-2026-10-16]]. Final pending-load outcome, page ACK и network attribution episode пока отсутствуют; весь production Others эти данные не объясняют.
|
||||
|
||||
## Исторический контекст — 15 октября 2026
|
||||
|
||||
> **Текущий статус — 15 октября 2026:** [[cpm-status-2026-10-15]]. Актуальная карта файлов и worktree — [[cpm-web-extension-code-guide-2026-10-09]] (§0). «Ничего не закоммичено», общий ready-handshake worktree и counts ниже относятся к состоянию 8–9 октября; A/B/telemetry уже разделены на PR, их актуальные heads/CI проверены в основном статусе.
|
||||
>
|
||||
> Новое продолжение в `alex/cpm-web-extension-remaining-failures`: 14 P5/P6 методов с green по отдельным логам, включая shared-window callback → system WebKit → P5/tab=false и условный main-flag handler cycle → P6. Факт flag-transition у пользователей и естественный вход P5/tab=true/listener metadata неизвестны. Контроли не дали P5 при длинных документах, одном missing-listener wake или host main-actor stall. Embedded-only first-init loss относится к A; после explicit ready wait controller остаётся correct.
|
||||
|
||||
@@ -10,6 +10,14 @@ tags:
|
||||
|
||||
# CPM Web Extension failures: reproduction and fixes
|
||||
|
||||
> **Current context — checked 20 October 2026.** This is the historical October 8 reproduction summary. The “all code local / none in review” and original phase-1 sections below are superseded; historical results are retained.
|
||||
>
|
||||
> Current implementations: #7379 P1/P2/P4, #7459 Network recovery with an applied daily+count pixel, #7493 restricted stable-origin P3 policy, and #7473 shared-pinned window close. Exact heads, bases, failure annotations and gates: [[cpm-status-2026-10-15#2. PR и quality gates]]; sources: [[cpm-web-extension-code-guide-2026-10-09#0. Текущая карта worktree и точек входа]].
|
||||
>
|
||||
> #7376 now contains one terminal episode report with four-value `stuck` and two-phase `bg_events`, daily+count; it is closed without merge. #7378/#7384 are also closed without merge, while #7385 and extension #3727 remain open. Full current telemetry contract: [[cpm-pr0-episode-telemetry-summary-2026-10-16]]. No page ACK or full explanation of production Others is provided.
|
||||
|
||||
## Historical context — recorded 15 October 2026
|
||||
|
||||
> **Current status — 2026-10-15:** [[cpm-status-2026-10-15]]; current code/worktree map: [[cpm-web-extension-code-guide-2026-10-09]] (§0). The October 8 summary below is retained as history. Its “all code local / none in review” statement is no longer current: harness #7378, A #7379, B #7381 and telemetry #7376/#7384/#7385 plus JS #3727 are open PRs. B's local fix is still absent from its red remote head.
|
||||
>
|
||||
> New evidence: closing a window that still reports a shared pinned tab makes system WebKit forget the surviving tab and reproduces exact P5/tab=false. Cycling the main flag through the production handler reproduces P6 on a view retaining the previous controller; occurrence of that flag transition in production remains unproven. Browser callbacks/delegates are modeled from source in the harness; this is not a full browser-app E2E run.
|
||||
|
||||
Reference in new issue
Block a user