Когда верстаешь адаптив, постоянно скачешь между десктопом и мобильной версией: то DevTools в режиме устройства, то ресайз окна, то открыть на телефоне. Десктоп и мобайл при этом никогда не видны одновременно — один прячется, когда смотришь на другой. А при показе работы заказчику демонстрация «узкого окна браузера» по видеосвязи выглядит так себе.

Готовые решения, конечно, есть. Я смотрел на мобильные симуляторы из Chrome Web Store — например «Mobile First»

«Симулятор телефона — мобильный»

и «U-eyes — мобильный симулятор»

Они прекрасно выполняют свою роль: дают набор устройств, вьюпорты, удобный предпросмотр. Но почти все они открывают превью в отдельном окне или в своей собственной области, и ни один не давал главного, что мне было нужно — быстро и удобно посмотреть адаптивное устройство прямо на вкладке, поверх десктопной версии, одновременно с ней. Хотелось видеть именно это: десктоп и телефон рядом, на той же странице, без переключений.

Поэтому я сделал свой инструмент. В статье — как это устроено технически: где были подводные камни и как я их обходил.

Идея

Расширение по клику строит оверлей: рамку телефона/планшета поверх текущей страницы, а внутри рамки — та же самая страница, но в мобильном вьюпорте. Прокрутка, клики и ввод синхронизируются между десктоп-страницей и превью.

Сразу встал главный вопрос: как отрендерить страницу внутри неё самой?

Проблема №1: страница в iframe, которую нельзя зафреймить

Очевидное решение — засунуть тот же URL в iframe и сузить его до ширины телефона. Но большинство сайтов отдают заголовки, которые запрещают встраивание:

• X-Frame-Options: SAMEORIGIN / DENY

• Content-Security-Policy: frame-ancestors …

iframe с такой страницей просто не загрузится.

Решение — declarativeNetRequest (MV3). Я динамически добавляю правило, которое для запросов превью-фрейма:

• срезает X-Frame-Options;

• вырезает из CSP только директиву frame-ancestors (не трогая остальной CSP);

• подменяет User-Agent на мобильный, чтобы сайт отдал мобильную вёрстку и сработали media-queries, завязанные на UA.

Важные ограничения, чтобы это было безопасно и не «протекало»:

• правило живёт только на время открытого превью и снимается при закрытии;

• оно ограничено конкретной вкладкой;

• никакие запросы не блокируются, не логируются и никуда не отправляются — меняются только заголовки ответа для рендера фрейма.

Проблема №2: оверлей не должен ломать стили сайта

Оверлей (рамка, панель управления, кнопки) рендерится на чужой странице, где какой угодно CSS. Чтобы стили сайта не поехали от моих и наоборот, весь UI живёт в Shadow DOM. Это даёт изоляцию стилей почти бесплатно: мои классы не конфликтуют с классами сайта.

Проблема №3: синхронизация прокрутки, кликов и ввода

Хотелось, чтобы можно было, например, заполнять форму на десктопе и видеть, как она заполняется в телефоне. Поскольку фрейм — это та же страница, я слушаю события на одной стороне и воспроизвожу на другой: scroll, клики по соответствующим элементам, ввод в поля. Тут много нюансов с маппингом элементов и защитой от бесконечных циклов событий (когда синхронизированное действие снова триггерит событие).

Скриншоты

Функция скриншота снимает видимое превью, локально обрезает по рамке устройства и отдаёт картинку как загрузку файла. Всё происходит на устройстве, ничего никуда не грузится.

Запись экрана

Здесь стоит быть честным про текущее состояние.

В сейчас опубликованной версии запись работает «стандартным» путём: через штатный диалог захвата экрана браузера (то самое разрешение от Google, где вы сами выбираете, что записывать). Видео кодируется локально и сохраняется на устройство файлом. Доступны два формата: WebM и MP4 (MP4 пока в тестовом режиме).

Параллельно я допиливаю более «бесшовный» вариант записи — без промпта на расшаривание и без сужения вьюпорта. Архитектурно он выглядит так:

• content-скрипт шлёт в background команды recStart / recStop;

• захват идёт через chrome.tabCapture + getUserMedia в offscreen-документе (в MV3 у service worker нет доступа к DOM/медиа, поэтому нужен offscreen);

• offscreen возвращает мастер-видео, а при скачивании content лениво инжектит муксеры (mp4-muxer / webm-muxer) и через WebCodecs перекодирует мастер в выбранный формат (MP4 H.264 / WebM VP9) и качество (1080/720/480).

Этот путь с ручным энкодером на WebCodecs — отдельная история с настройкой энкодера, таймстампами кадров и сборкой контейнера. Пока он в разработке; в релизе остаётся стабильный вариант со штатным захватом.

Приватность как ограничение архитектуры

Я сознательно делал так, чтобы расширению нечего было «сливать»: нет бэкенда, нет аналитики внутри расширения, нет удалённого кода. Настройки (выбранное устройство, ориентация, масштаб, тема) лежат в chrome.storage.local и не покидают устройство. Список вкладок с открытым превью — в chrome.storage.session, чтобы восстановиться после перезагрузки; это только идентификаторы вкладок, без содержимого и URL.

Разрешения в манифесте — ровно под задачу: activeTab, scripting, declarativeNetRequest, storage, notifications и host-доступ для рендера превью на любом сайте.

Итог

Получилось расширение Mobile View — десктоп и мобильная вёрстка одновременно, прямо на вкладке: синхронизация, скриншоты и запись экрана, всё локально. Оно бесплатное и лежит в Chrome Web Store.

Буду рад фидбэку именно по технической части: как бы вы решали обход X-Frame-Options, синхронизацию событий или перекодирование на WebCodecs иначе? И если найдёте баги на своей ОС/версии браузера — расскажите, очень помогает.

Ссылка на расширение: https://chromewebstore.google.com/detail/mobile-view-mobile-simu/hocbjiaeeijekejepphjihbpogikmofh