Mark 2e3f5248ce fix(01-review): CR-01+CR-02+CR-03+WR-03+WR-09 critical port + handshake race fixes
What was wrong:
- CR-01 (recorder.ts): encodeAndSendBuffer captured no port identity before
  awaiting Promise.all(blobToBase64). If the port disconnected mid-encode
  and onDisconnect synchronously reconnected (re-assigning keepalivePort
  to a fresh instance), the post-await null-check evaluated false and
  the BUFFER was posted on the NEW port — but the SW's per-request
  onMessage listener was still bound to the OLD port (captured at
  getVideoBufferFromOffscreen line 110). Result: SW timed out after
  2 s, SAVE_ARCHIVE produced an empty-segments zip, data-loss path
  masquerading as a benign timeout.
- CR-02 (background/index.ts): SW's onConnect handler attached
  ONLY onDisconnect — no permanent onMessage sink. PING traffic
  had no listener when getVideoBufferFromOffscreen wasn't running
  (the normal idle state of the port), and field reports note Chrome's
  SW idle-timer reset behaves inconsistently when no listener is
  attached. Risk: PINGs silently dropped, SW evicted ~30 s into
  recording, port torn down, next SAVE_ARCHIVE fails entirely.
- CR-03 (background/index.ts): offscreenReady is a one-shot Promise
  resolved on the FIRST OFFSCREEN_READY message. If the SW is evicted
  while the offscreen document persists, the next SW lifetime creates
  a fresh Promise and waits on it forever — the offscreen never
  re-emits OFFSCREEN_READY. startVideoCapture() hangs at
  `await offscreenReady` until Chrome restarts.
- WR-03 (recorder.ts): `baseTimestamp + idx` (Date.now() + idx) used
  millisecond resolution + array offset. Two REQUEST_BUFFER calls
  within the same millisecond would collide, breaking the sort-by-
  timestamp contract in SW-side mergeVideoSegments.
- WR-09 (recorder.ts): encodeAndSendBuffer always appended the
  unfinalized in-flight segment to the BUFFER. That segment lacks
  the Matroska SegmentSize and Cues that MediaRecorder.stop()
  writes — re-introducing the "File ended prematurely" symptom
  documented in debug session webm-playback-freeze.

What changed:
- recorder.ts encodeAndSendBuffer:
  - Capture `portAtRequest = keepalivePort` BEFORE the encode.
  - After the await, refuse to post if `keepalivePort !== portAtRequest`
    (port was replaced by reconnect). SW already times out cleanly
    after BUFFER_FETCH_TIMEOUT_MS = 2 s; the next SAVE_ARCHIVE
    re-issues REQUEST_BUFFER on the fresh port. Stale data
    NEVER reaches a stranger port.
  - Include the in-flight segment ONLY when finalized.length === 0
    (preserve the SAVE-within-first-10-s UX trade-off documented at
    the original comment) — otherwise drop the unfinalized tail.
  - Replace `baseTimestamp + idx` with module-level monotonic
    `++segmentSeq` counter (zero wall-clock dependency).
  - Switch from Promise.all/map+filter to a sequential for-loop
    because each iteration now mutates the shared `segmentSeq`;
    Promise.all timing would interleave assignments. Throughput
    impact negligible (3 segments × ~50 ms base64 each ≈ 150 ms
    vs ~50 ms parallel — still well under the 2 s SW budget).

- background/index.ts onConnect:
  - Install a permanent `port.onMessage.addListener` that
    explicitly drains PING and silently drops unknown traffic.
    Per-request BUFFER listener still wins because it's attached
    LATER in the listener chain when getVideoBufferFromOffscreen
    fires; this sink only catches the idle PING stream and
    guarantees the SW idle-timer reset is consumed by a real
    handler.

- background/index.ts initialize():
  - When `chrome.offscreen.hasDocument()` returns true on SW init,
    immediately resolve `offscreenReady` AND null
    `offscreenReadyResolve`. The offscreen MUST have completed its
    bootstrap before it was observable via hasDocument(); waiting
    for an OFFSCREEN_READY that will never come is a deadlock.

Why these fixes vs alternatives:
- CR-01: alternatives considered: (a) cancel encoding when port
  disconnects (requires AbortController plumbing into blobToBase64);
  (b) re-route the BUFFER through the new port via a per-port
  request-id correlation. Both add machinery for a case the SW
  already handles correctly (2 s timeout → retry). The capture-
  identity check is the minimum-mechanism fix and matches REVIEW.md
  CR-01 fix guidance exactly.
- CR-02: alternative considered: documenting "rely on kernel-level
  port-message side effect for idle-timer reset" — REJECTED, this
  is what the existing comment did and the field evidence shows
  it's unreliable. Explicit listener is the safe default.
- CR-03: alternative considered: (a) have offscreen re-emit
  OFFSCREEN_READY on every inbound SW message — adds noise to
  the message bus and races with the original-bootstrap-emit.
  Option (b) (resolve-on-hasDocument-true) is simpler, narrower,
  and was explicitly recommended by REVIEW.md.
- WR-03: alternative considered: keeping Date.now() and adding a
  microsecond-resolution offset via performance.now() — fragile
  across SW respawns where performance.now() resets. Module-level
  monotonic counter has zero wall-clock dependency.
- WR-09: alternative considered: forcing a synchronous rotation
  at REQUEST_BUFFER time. Rejected — adds ~50–200 ms latency to
  every save AND races with scheduleRotation()'s timer. The
  "exclude unless empty" trade-off matches REVIEW.md option (a)
  exactly and preserves the documented first-10-s UX path.

Validation evidence:
- npx tsc --noEmit: exit 0 (no type errors).
- npx vitest run --reporter=dot: 30/30 tests pass in 2.67 s
  (8 test files, including port.test.ts which pins the reconnect
  invariant and port-serialization.test.ts which pins the wire format).
- grep "as any\|@ts-ignore" src/offscreen/ src/background/index.ts
  src/shared/: no matches (type-safety gate stays clean).
2026-05-16 09:21:34 +02:00

AI Call Recorder - Браузерное расширение для записи сессий операторов

Фаза 1 — Локальная запись + экспорт архива

Установка и запуск

Разработка

# Установка зависимостей
npm install

# Сборка для разработки с HMR
npm run dev

# Сборка для продакшена
npm run build

Установка расширения в Chrome

  1. Соберите проект:

    npm run build
    
  2. Откройте Chrome и перейдите по адресу: chrome://extensions/

  3. Включите "Режим разработчика" (Developer mode) в правом верхнем углу

  4. Нажмите кнопку "Загрузить распакованное расширение" (Load unpacked)

  5. Выберите папку dist в корне проекта

  6. Расширение установлено!

Использование

  1. При первом открытии popup расширение запросит разрешение на запись экрана

  2. Разрешение обязательно для работы расширения

  3. Расширение автоматически начнет запись:

    • Видео: последние 30 секунд (кольцевой буфер)
    • DOM-события через rrweb: последние 10 минут
    • Лог действий пользователя: последние 10 минут
  4. Для сохранения отчета об ошибке:

    • Нажмите на иконку расширения
    • Нажмите кнопку "Сохранить отчёт об ошибке"
    • Архив автоматически загрузится в папку "Загрузки"

Структура архива

Архив session_report_YYYY-MM-DD_HH-MM-SS.zip содержит:

session_report_2025-05-15_14-32-10.zip
├── video/
│   └── last_30sec.webm         # склеенные чанки видеобуфера
├── rrweb/
│   └── session.json            # массив DOM-событий rrweb
├── logs/
│   └── events.json             # лог действий пользователя
├── screenshot.png              # скриншот в момент сохранения
└── meta.json                   # метаданные сессии

Технический стек

  • Тип расширения: Chrome Extension, Manifest V3
  • Service Worker: Background script (Manifest V3)
  • Захват экрана: chrome.tabCapture API
  • Захват DOM: rrweb (npm: rrweb)
  • Лог событий: Content Script
  • Упаковка архива: JSZip (npm: jszip)
  • Сохранение файла: chrome.downloads API
  • Хранение буфера: In-memory (Service Worker + Content Script)
  • Build: Vite + crxjs + TypeScript

Особенности

Маскирование чувствительных данных

  • Пароли (input[type=password]) маскируются автоматически в rrweb и логах
  • Поля с атрибутом data-sensitive="true" также маскируются в rrweb

Записываемые события

Пользовательские события

  • click — клик по любому элементу
  • input — изменение значения поля (без паролей)
  • navigation — переходы по страницам (popstate, hashchange, History API)
  • js_error — JavaScript ошибки (window.onerror, unhandledrejection)
  • network_error — сетевые ошибки (fetch/XHR с кодом ответа >= 400)

Кольцевой буфер

  • Видео: 30 секунд, первый чанк (WebM заголовок) хранится всегда
  • rrweb события: 10 минут, максимум 5000 событий
  • Пользовательские события: 10 минут

Память

  • Ожидаемое потребление: ~5-10 МБ в фоновом режиме

Критерии приёмки Фазы 1

  • Расширение устанавливается в Chrome без ошибок
  • Видеобуфер непрерывно работает на любой вкладке
  • В буфере всегда есть не более 30 секунд видео
  • rrweb пишет DOM-события без ошибок на типовых страницах
  • Лог событий фиксирует клики, навигацию и сетевые ошибки
  • При нажатии кнопки архив скачивается в "Загрузки" за < 5 секунд
  • Архив открывается, last_30sec.webm воспроизводится в браузере
  • Пароли не попадают в лог и rrweb-снимки
  • RAM-потребление расширения не превышает 50 МБ в фоне

Отладка

Console Logs

Расширение пишет подробные логи в консоль:

  • Service Worker: Chrome DevTools → Extensions → Service Worker → Console
  • Content Script: Chrome DevTools на любой странице → Console
  • Popup: Правый клик по popup → Проверить

Структура проекта

ai-call-extension/
├── src/
│   ├── background/          # Service Worker
│   │   └── index.ts
│   ├── content/            # Content Script
│   │   └── index.ts
│   ├── popup/              # Popup UI
│   │   ├── index.html
│   │   ├── index.ts
│   │   └── style.css
│   └── shared/             # Общие типы и утилиты
│       ├── types.ts
│       └── logger.ts
├── icons/                  # Иконки расширения
├── dist/                   # Собранные файлы
├── manifest.json           # Manifest расширения
├── vite.config.ts          # Конфигурация Vite
├── tsconfig.json           # Конфигурация TypeScript
└── package.json

Лицензия

MIT

Контакты

Для вопросов и предложений обращайтесь в support.

Description
No description provided
Readme 8 MiB
Languages
TypeScript 91%
HTML 3.4%
CSS 2.8%
Shell 2%
JavaScript 0.8%