Известные проблемы при переходе на Manifest V3

На этой странице описаны недостатки платформы, устраненные в ходе перехода на Manifest V3, а также даны ответы на часто задаваемые вопросы о миграции.

Устранены недостатки платформы.

Для решения распространенных проблем, препятствующих миграции, были добавлены следующие возможности:

  1. Поддержка обработки файлов в ChromeOS в качестве замены chrome.fileBrowserHandler (Chrome 120).
  2. Поддержка пользовательских скриптов: Позволяет регистрировать скрипты контента с произвольным кодом с помощью нового API userScripts (Chrome 120).
  3. Для некоторых операций, занимающих более пяти минут, требуется дополнительное поддержание связи с высококвалифицированными сотрудниками службы поддержки .
    • Добавлено в Chrome 116 для permissions.request() , desktopCapture.chooseDesktopMedia() , identity.launchWebAuthFlow() и management.uninstall() .
    • Добавлено в Chrome 118 для chrome.debugger .
  4. Увеличено количество статических и включенных наборов правил для декларативного сетевого запроса (DNR). Количество включенных статических наборов правил увеличено с 10 до 50, а общее количество статических наборов правил — с 50 до 100 (Chrome 120).
  5. Расширена функциональность документов, отображаемых вне экрана , для поддержки большего количества причин их использования. Добавлена GEOLOCATION в Chrome 116.
  6. Улучшена поддержка API chrome.tabCapture (Chrome 116):
    • Поддерживается вызов метода getMediaStreamId() из сервис-воркера.
    • Поддерживается получение MediaStream из идентификатора потока в документе, находящемся вне экрана.
  7. Увеличение времени жизни сервис-воркеров при наличии активных WebSocket соединений (Chrome 116).

Часто задаваемые вопросы по Manifest V3

В: Планируем ли мы оказывать поддержку работникам сферы услуг, которые работают на постоянной основе?
А: Одна из ключевых причин перехода от фоновых скриптов к сервис-воркерам — более эффективная с точки зрения использования памяти событийно-ориентированная модель программирования, обусловленная временным характером сервис-воркеров. Следовательно, мы не планируем поддерживать постоянные сервис-воркеры. Однако, чтобы удовлетворить специфические потребности разработчиков расширений, мы продолжаем вносить множество улучшений в сервис-воркеры. В частности:

  • Все события расширения и вызовы API продлевают время жизни сервис-воркера .
  • В некоторых сценариях использования, таких как встроенная система обмена сообщениями, службы расширения будут оставаться активными дольше 5 минут.

В: Существует ли способ получить доступ к DOM в сервис-воркерах?
A: Мы придерживаемся подхода, принятого веб-платформой, а именно не включаем доступ к DOM в веб-воркеры (включая сервис-воркеры). Для поддержки сценариев использования, требующих фонового доступа к DOM из сервис-воркеров, мы ввели возможность делегировать фоновую работу кратковременным документам Offscreen , которые обеспечивают полный доступ к DOM.

В: Будет ли возможность поддерживать удаленный код в Manifest V3?
A: Чтобы повысить безопасность расширений Chrome, мы продолжим запрещать выполнение произвольного удаленно размещенного кода в расширениях Chrome. Однако это не означает, что мы запрещаем все виды динамического выполнения кода. Мы по-прежнему поддерживаем различные варианты динамического выполнения кода в расширениях Chrome:

В: Мое расширение в Manifest V2 использует webRequestBlocking, который не поддерживается в Manifest V3. Как я могу сохранить ту же функциональность в Manifest V3?
A: Мы уверены, что большинство сценариев блокировки запросов можно решить с помощью нового API declarativeNetRequest , который имеет дополнительное преимущество в виде избежания накладных расходов на производительность, связанных с межпроцессным взаимодействием, выполнением кода при каждом запросе или необходимостью активного процесса расширения во время запроса. Однако для сложных корпоративных (или образовательных) сценариев динамическая блокировка запросов по-прежнему поддерживается.

Мы что-то упустили? Пожалуйста, сообщите нам .