Недавно мы объявили об изменениях в графике прекращения поддержки 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 , который имеет дополнительное преимущество, позволяющее избежать накладных расходов на производительность межпроцессного взаимодействия, выполнения кода при каждом запросе или требования активного процесса расширения во время запрос. Однако для сложных случаев использования на предприятии (или в сфере образования) динамическая блокировка запросов по-прежнему поддерживается.
Мы что-то пропустили? Пожалуйста дай нам знать .