Эта страница переведена с помощью Cloud Translation API.

Закадровые документы в манифесте V3

Ian Stanion

Чтобы заменить функциональность при переходе от фоновых страниц к работникам службы расширений, разработчики могут использовать API chrome.offscreen и разрешение манифеста, начиная с Chrome 109. Запрос этого разрешения позволяет создавать закадровые документы для использования API DOM без навязчивого открытия новых. окна или вкладки, которые мешают работе пользователя. API chrome.offscreen теперь доступен в расширениях Chrome.

В Chromium расширения Manifest V3 основаны на сервис-воркерах, но сервис-воркеры не обеспечивают поддержку тех же API и механизмов, что и полные страницы на основе документов (которые включают фоновые страницы и страницы событий). Кроме того, использование сценариев контента для доступа к API DOM на веб-страницах оставляет расширение во власти различных политик безопасности контента на каждой странице. Чтобы помочь решить эту проблему, мы представляем Offscreen Documents для поддержки функций и API, связанных с DOM, позволяя расширениям Manifest V3 открывать минимальные, ограниченные и относительно неразрешенные внеэкранные документы во время выполнения через специальный API.

Информация о функции

Поскольку закадровые документы специально разработаны для обработки случаев использования, которые не поддерживаются в сервис-воркерах (например, воспроизведение звука), время существования этой страницы и разрешения, которые ей будут предоставлены, отличаются от разрешений, которые предоставляет расширенный сервис-воркер. Страница будет иметь механизм срока действия, аналогичный страницам событий в Манифесте V2: она будет удалена, когда перестанет выполнять действия. Кроме того, пользовательский агент может наложить дополнительные ограничения на время жизни, специфичные для указанной цели. Offscreen документы предназначены для заполнения пробелов в API, которые доступны только для API DOM; из-за этого API-интерфейсы расширений не нужно предоставлять напрямую в этом контексте. Чтобы снизить вероятность того, что расширения будут использовать их в качестве «замены фоновой страницы», закадровому документу доступны только API-интерфейсы обмена сообщениями chrome.runtime . (Разработчики также могут использовать обмен веб-сообщениями, заявив, что закадровый документ является клиентом через своего сервис-воркера.) Поскольку в некоторых случаях использования, в частности, при очистке сайта, требуется доступ к фреймам из разных источников, мы разрешаем в эти документы встраивать фреймы из разных источников. следуя тем же правилам, что и страницы расширений сегодня. В закадровых документах в этих фреймах могут выполняться сценарии содержимого, указанные расширением, для извлечения любого необходимого содержимого, как и для любой обычной веб-страницы.

Причины и необходимость цели

Для создания закадрового документа необходимы указанные причины и дальнейшее обоснование. Эти причины перечислены в справочной документации API и по-разному определяют время существования документа. Например, к документу, открытому для воспроизведения звука, в настоящее время применяются другие правила, чем к документу, открытому для управления буфером обмена. Вы также можете добавить дополнительную информацию о назначении закадрового документа в обоснование, которое представляет собой строку, написанную разработчиком, а не параметр, влияющий на документ. Со временем в API могут быть добавлены дополнительные причины по мере того, как разработчики будут делиться своими отзывами и вариантами использования.

В будущее

Для простоты реализации первая версия этого API поддерживает одновременно только одну страницу для каждого расширения и каждого профиля. В будущих версиях мы можем ослабить эту настройку для поддержки нескольких страниц. В настоящее время, если расширение работает в разделенном режиме с активным профилем инкогнито, каждый из обычных профилей и профилей инкогнито может иметь по одному документу за кадром. Позже также планируется предоставить функциональность DOM для рабочего расширения. Вы можете «подготовить» свои расширения к будущему, объединив функции, использующие внеэкранный API, с эквивалентной комментируемой функцией в сервис-воркере для замены позднее.

// Solution 1 - Service workers cannot directly interact with
// the system clipboard. To work around this, we'll create an offscreen
// document and pass the data we want to write to the clipboard.
async function addToClipboard(value) {
    await chrome.offscreen.createDocument({
      url: 'offscreen.html',
      reasons: [chrome.offscreen.Reason.CLIPBOARD],
      justification: 'Write text to the clipboard.',
    });
  }


// Solution 2 – Once extension service workers can use the Clipboard API,
// replace the offscreen document based implementation with something like this
async function addToClipboardV2(value) {
  navigator.clipboard.writeText(value);
}

Кроме того, по мере добавления к сервис-воркеру функций DOM и API-интерфейсов список причин для создания документа будет добавляться или уменьшаться в зависимости от текущего состояния сервис-воркера и причин использования закадровых документов.

Заключение

Offscreen Documents допускают расширения, требующие доступа к DOM или взаимодействию с окном, чего в настоящее время невозможно достичь в сервисных работниках. Он также обеспечивает гибкий подход, при котором можно добавлять новые варианты использования и удалять варианты использования, решаемые в будущем. Расширения должны использовать предлагаемый API закадрового документа для конкретных случаев использования, а основным фоновым контекстом расширения должен оставаться сервис-воркер, указанный в манифесте. Закадровый документ не должен быть местом для хранения основной логики расширения, поскольку он имеет ограниченный доступ к API. Срок существования закадрового документа не зависит от сервис-воркера, создавшего его. Рекомендации по сроку службы Service Worker и варианты использования, связанные со временем жизни Service Worker в расширениях, будут рассмотрены в отдельной публикации в блоге. Причины использования закадровых документов будут меняться со временем по мере добавления функций и API к самому сервисному работнику. Мы с нетерпением ждем отзывов разработчиков по мере развития событий.

Фото Кари Ши на Unsplash