Недавно мы объявили об изменениях в графике прекращения поддержки Manifest V2, и, хотя мы по-прежнему твердо привержены Manifest V3, мы признаем, что с нашей стороны предстоит еще много работы.
- Прежде чем объявить о новом графике прекращения поддержки, мы завершили устранение приоритетных недостатков платформы и закрыли критические ошибки, которые были задокументированы на этой странице.
- Мы дали разработчикам время на разработку, гарантировав не менее шести месяцев между объявлением графика и предстоящими экспериментами по прекращению поддержки Manifest V2.
Устранение разрыва в платформах
Мы стремимся устранить следующие пробелы, прежде чем объявить новый график прекращения поддержки Manifest V2:
Проблемы собирались на основе отзывов партнеров, отчетов об ошибках и разработчиков. Мы продолжим нашу постоянную работу по улучшению стабильности и общей производительности платформы расширений.
В настоящее время нет открытых проблем, которые считаются критическим недостатком платформы.
Недавно были решены следующие проблемы:
- Поддержка обработки файлов в ChromeOS в качестве замены
chrome.fileBrowserHandler[Chrome 120]. - Поддержка пользовательских сценариев: разрешите регистрацию сценариев контента с произвольным кодом с помощью нового API userScripts [Chrome 120].
- Дополнительные мощные службы поддержки для некоторых операций, занимающих более пяти минут.
- Добавлено в Chrome 116 для
permissions.request(),desktopCapture.chooseDesktopMedia(),identity.launchWebAuthFlow()иmanagement.uninstall(). - Добавлен в Chrome 118 для
chrome.debugger
- Добавлено в Chrome 116 для
- Увеличьте количество статических и включенных наборов правил для декларативного сетевого запроса (DNR). Число включенных статических наборов правил увеличено с 10 до 50, а общее количество статических наборов правил — с 50 до 100 [Chrome 120].
- Расширьте функциональность документа за кадром, чтобы указать больше причин для использования документа за кадром. Добавлена
GEOLOCATIONв Chrome 116. - Улучшение поддержки API
chrome.tabCapture[Chrome 116]:- Поддержка вызова
getMediaStreamId()от сервис-воркера. - Поддержка получения
MediaStreamиз идентификатора потока в закадровом документе.
- Поддержка вызова
- Увеличение времени жизни сервис-воркера при наличии активных соединений
WebSocket[Chrome 116].
Манифест V3: часто задаваемые вопросы
Вопрос: Планируем ли мы поддерживать постоянные сервисные работники?
Ответ: Одной из ключевых причин перехода от фоновых сценариев к сервис-воркерам является более эффективная модель программирования, управляемая событиями, которая обусловлена эфемерной природой сервис-воркеров. Следовательно, мы не планируем поддерживать постоянных сервис-работников. Однако, чтобы удовлетворить конкретные потребности разработчиков расширений, мы продолжаем вносить множество улучшений в сервис-воркеры. В частности:
- Все события расширения и вызовы API продлевают срок службы сервис-воркера .
- Отдельные варианты использования, такие как собственный обмен сообщениями, сохранят работоспособность сотрудников службы расширений более 5 минут.
Вопрос: Есть ли способ получить доступ к DOM в сервис-воркерах?
О: Мы следуем подходу, принятому веб-платформой, не включая доступ к DOM в веб-воркеры (включая сервис-воркеров). Для поддержки случаев использования, требующих фонового доступа к DOM со стороны сервисных работников, мы представили возможность делегировать фоновую работу кратковременным документам Offscreen , которые обеспечивают полный доступ к DOM.
Вопрос: Будет ли возможность поддерживать удаленный код в Manifest V3?
О: Чтобы сделать расширения Chrome более безопасными, мы продолжим запрещать выполнение произвольного удаленно размещенного кода в расширениях Chrome. Однако это не означает, что мы запрещаем все виды динамического выполнения кода. Мы по-прежнему поддерживаем различные варианты динамического выполнения кода в расширениях Chrome:
- Поддержка
eval()в расширениях DevTools. - Поддержка пользовательских скриптов .
- Выполнение удаленно размещенного кода в изолированных фреймах iframe
- Удаленно размещенные файлы конфигурации, которые можно интерпретировать во время выполнения в пакете расширения. Однако возможные пути выполнения должны быть заранее определены.
Вопрос: Мое расширение Manifest V2 использует webRequestBlocking, который не поддерживается в Manifest V3. Как я могу продолжать предоставлять ту же функциональность в Manifest V3?
О: Мы уверены, что большинство случаев использования блокировки запросов можно решить с помощью нового API declarativeNetRequest , который имеет дополнительное преимущество, позволяющее избежать накладных расходов на производительность межпроцессного взаимодействия, выполнения кода при каждом запросе или требования активного процесса расширения во время запрос. Однако в сложных случаях использования на предприятии (или в сфере образования) динамическая блокировка запросов по-прежнему поддерживается.
Мы что-то пропустили? Пожалуйста дай нам знать .