2e3f5248cee472fd3bc43c0434c6b132cbd32bc3
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).
AI Call Recorder - Браузерное расширение для записи сессий операторов
Фаза 1 — Локальная запись + экспорт архива
Установка и запуск
Разработка
# Установка зависимостей
npm install
# Сборка для разработки с HMR
npm run dev
# Сборка для продакшена
npm run build
Установка расширения в Chrome
-
Соберите проект:
npm run build -
Откройте Chrome и перейдите по адресу:
chrome://extensions/ -
Включите "Режим разработчика" (Developer mode) в правом верхнем углу
-
Нажмите кнопку "Загрузить распакованное расширение" (Load unpacked)
-
Выберите папку
distв корне проекта -
Расширение установлено!
Использование
-
При первом открытии popup расширение запросит разрешение на запись экрана
-
Разрешение обязательно для работы расширения
-
Расширение автоматически начнет запись:
- Видео: последние 30 секунд (кольцевой буфер)
- DOM-события через rrweb: последние 10 минут
- Лог действий пользователя: последние 10 минут
-
Для сохранения отчета об ошибке:
- Нажмите на иконку расширения
- Нажмите кнопку "Сохранить отчёт об ошибке"
- Архив автоматически загрузится в папку "Загрузки"
Структура архива
Архив 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.tabCaptureAPI - Захват DOM:
rrweb(npm: rrweb) - Лог событий: Content Script
- Упаковка архива:
JSZip(npm: jszip) - Сохранение файла:
chrome.downloadsAPI - Хранение буфера: 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
Languages
TypeScript
91%
HTML
3.4%
CSS
2.8%
Shell
2%
JavaScript
0.8%