최근 Google은 Manifest V2 지원 중단 타임라인의 변경사항을 발표했으며, Manifest V3에 대한 약속은 계속 지키면서도 아직 해야 할 일이 더 있음을 알고 있습니다.
- 새로운 지원 중단 일정을 발표하기 전에 우선 순위가 지정된 플랫폼 격차를 해소하고 이 페이지에서 다룬 치명적인 버그를 해결했습니다.
- 타임라인 공지 후 Manifest V2 지원 중단을 위한 대기 중인 실험까지 최소 6개월의 기간을 보장함으로써 개발자에게 빌드할 시간을 제공했습니다.
플랫폼 간극 해소
Google은 새로운 Manifest V2 지원 중단 타임라인을 발표하기 전에 다음과 같은 간극을 메우기 위해 최선을 다하고 있습니다.
문제는 파트너, 버그 신고, 개발자의 의견을 기반으로 수집되었습니다. Google은 확장 프로그램 플랫폼의 안정성과 전반적인 성능을 개선하기 위해 지속적인 노력을 기울일 것입니다.
현재 심각한 플랫폼 격차로 간주되는 미해결 문제가 없습니다.
최근 해결된 문제는 다음과 같습니다.
chrome.fileBrowserHandler
[Chrome 120]을 대체하는 ChromeOS의 파일 처리 지원.- 사용자 스크립트 지원: 새로운 userScripts API[Chrome 120]를 사용하여 임의의 코드가 포함된 콘텐츠 스크립트를 등록할 수 있습니다.
- 5분 넘게 걸리는 특정 작업에 대한 추가적인 강력한 서비스 워커 연결 유지가 가능합니다.
permissions.request()
,desktopCapture.chooseDesktopMedia()
,identity.launchWebAuthFlow()
,management.uninstall()
용으로 Chrome 116에 추가되었습니다.chrome.debugger
용 Chrome 118에 추가됨
- 선언적 순 요청 (DNR)의 정적 및 사용 설정된 규칙 세트의 수를 늘립니다. 사용 설정된 정적 규칙 세트가 10개에서 50개로, 총 정적 규칙 세트가 50개에서 100개로 늘어났습니다[Chrome 120].
- 화면 밖 문서 기능을 확장하여 화면 밖 문서를 사용하는 더 많은 이유를 지원합니다. Chrome 116에
GEOLOCATION
가 추가되었습니다. chrome.tabCapture
API 지원 개선[Chrome 116]:- 서비스 워커에서
getMediaStreamId()
호출을 지원합니다. - 오프스크린 문서의 스트림 ID에서
MediaStream
를 가져올 수 있습니다.
- 서비스 워커에서
- 활성
WebSocket
연결이 있는 동안 서비스 워커 전체 기간 연장[Chrome 116]
Manifest V3 자주 묻는 질문(FAQ)
Q: 영구 서비스 워커를 지원할 계획이 있나요?
A: 백그라운드 스크립트를 서비스 워커로 마이그레이션하는 주요 이유 중 하나는 서비스 워커의 임시성에서 비롯된 메모리 효율적인 이벤트 기반 프로그래밍 모델입니다. 따라서 Google은 영구 서비스 워커를 지원할 계획이 없습니다. 그러나 확장 프로그램 개발자의 특정 요구를 충족하기 위해 서비스 워커에 대해 많은 개선 작업을 계속 진행하고 있습니다. 구체적인 방법은 다음과 같습니다.
- 모든 확장 프로그램 이벤트와 API 호출이 서비스 워커 전체 기간을 연장합니다.
- 기본 메시지와 같은 일부 사용 사례에서는 확장 프로그램 서비스 워커가 5분 이상 활성 상태로 유지됩니다.
Q: 서비스 워커에서 DOM에 액세스할 수 있는 방법이 있나요?
A: Google은 웹 워커 (서비스 워커 포함)에 DOM 액세스를 포함하지 않는 웹 플랫폼의 접근 방식을 따릅니다. 서비스 워커에서 백그라운드 DOM 액세스가 필요한 사용 사례를 지원하기 위해 전체 DOM 액세스를 제공하는 단기 화면 밖 문서에 백그라운드 작업을 위임할 수 있는 기능을 도입했습니다.
Q: Manifest V3에서 원격 코드를 지원하는 방법이 있나요?
A: Chrome 확장 프로그램의 보안을 강화하기 위해 Chrome 확장 프로그램에서 임의의 원격 호스팅 코드 실행을 계속 허용하지 않을 예정입니다. 그렇다고 해서 Google에서 모든 종류의 동적 코드 실행을 허용하지는 않습니다. Chrome 확장 프로그램에서 코드를 동적으로 실행하는 다양한 옵션을 계속 지원합니다.
- DevTools 확장 프로그램에서
eval()
지원 - 사용자 스크립트 지원
- 샌드박스 처리된 iframe에서 원격 호스팅 코드 실행
- 확장 프로그램 패키지에서 런타임에 해석될 수 있는 원격으로 호스팅되는 구성 파일입니다. 하지만 가능한 실행 경로는 미리 결정해야 합니다.
Q: Manifest V2 확장 프로그램에서 Manifest V3에서 지원되지 않는 webRequestBlocking을 사용합니다. Manifest V3에서 동일한 기능을 계속 제공하려면 어떻게 해야 하나요?
A: 요청 차단 사용 사례를 대부분 새로운 declarativeNetRequest
API로 해결할 수 있습니다. 새로운 declarativeNetRequest
API는 프로세스 간 통신의 성능 오버헤드를 피하거나, 모든 요청에 대해 코드를 실행하거나, 요청 시 활성 확장 프로세스를 요구한다는 추가 이점을 제공합니다. 하지만 복잡한 기업 (또는 교육) 사용 사례의 경우 동적 요청 차단이 계속 지원됩니다.
뭔가 놓치셨나요? 알려주세요.