Чтобы заменить функциональность при переходе от фоновых страниц к работникам служб расширений, разработчики могут использовать 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 к самому сервисному работнику. Мы с нетерпением ждем отзывов разработчиков по мере развития событий.