Các vấn đề đã biết khi di chuyển sang Manifest V3

Trang này ghi lại những điểm khác biệt về nền tảng đã được giải quyết trong quá trình chuyển đổi sang Manifest V3 và giải đáp các câu hỏi thường gặp về việc di chuyển.

Đã giải quyết các thiếu hụt về nền tảng

Chúng tôi đã bổ sung các chức năng sau để giải quyết những yếu tố thường cản trở quá trình di chuyển:

  1. Hỗ trợ Tính năng xử lý tệp trên ChromeOS để thay thế cho chrome.fileBrowserHandler (Chrome 120).
  2. Hỗ trợ tập lệnh người dùng: Cho phép đăng ký tập lệnh nội dung bằng mã tuỳ ý thông qua userScripts API mới (Chrome 120).
  3. Các lệnh duy trì hoạt động mạnh mẽ của trình chạy dịch vụ bổ sung cho một số thao tác mất hơn 5 phút.
    • Được thêm vào Chrome 116 cho permissions.request(), desktopCapture.chooseDesktopMedia(), identity.launchWebAuthFlow() và management.uninstall().
    • Được thêm vào Chrome 118 cho chrome.debugger.
  4. Tăng số lượng nhóm quy tắc tĩnh và được bật cho Declarative Net Request (DNR). Số lượng nhóm quy tắc tĩnh được bật tăng từ 10 lên 50 và tổng số nhóm quy tắc tĩnh tăng từ 50 lên 100 (Chrome 120).
  5. Mở rộng chức năng Tài liệu ngoài màn hình để hỗ trợ nhiều lý do hơn cho việc sử dụng tài liệu ngoài màn hình. Đã thêm GEOLOCATION trong Chrome 116.
  6. Cải thiện khả năng hỗ trợ cho API chrome.tabCapture (Chrome 116):
    • Hỗ trợ gọi getMediaStreamId() từ một trình chạy dịch vụ.
    • Hỗ trợ việc lấy MediaStream từ mã luồng trong một tài liệu ngoài màn hình.
  7. Kéo dài vòng đời của trình chạy dịch vụ khi có WebSocket kết nối đang hoạt động (Chrome 116).

Câu hỏi thường gặp về Manifest V3

Hỏi: Chúng tôi có dự định hỗ trợ Service Worker liên tục không?
Đáp: Một trong những lý do chính để di chuyển từ tập lệnh nền sang trình chạy dịch vụ là mô hình lập trình hướng sự kiện hiệu quả hơn về bộ nhớ, xuất phát từ bản chất tạm thời của trình chạy dịch vụ. Do đó, chúng tôi không có kế hoạch hỗ trợ các service worker liên tục. Tuy nhiên, để đáp ứng nhu cầu cụ thể của nhà phát triển tiện ích, chúng tôi vẫn tiếp tục cải thiện nhiều khía cạnh của worker dịch vụ. Cụ thể:

  • Tất cả các sự kiện tiện ích và lệnh gọi API sẽ kéo dài vòng đời của trình chạy dịch vụ.
  • Các trường hợp sử dụng được chọn, chẳng hạn như nhắn tin gốc, sẽ duy trì hoạt động của các worker dịch vụ tiện ích lâu hơn 5 phút.

Hỏi: Có cách nào để truy cập vào DOM trong các worker dịch vụ không?
Đáp: Chúng tôi tuân theo phương pháp của Nền tảng web là không đưa quyền truy cập DOM vào các worker trên web (bao gồm cả service worker). Để hỗ trợ các trường hợp sử dụng yêu cầu quyền truy cập DOM ở chế độ nền từ trình chạy dịch vụ, chúng tôi đã giới thiệu khả năng uỷ quyền công việc ở chế độ nền cho Tài liệu ngoài màn hình có thời gian tồn tại ngắn và cung cấp quyền truy cập DOM đầy đủ.

Hỏi: Có cách nào để hỗ trợ mã từ xa trong Manifest V3 không?
Đáp: Để tăng cường tính bảo mật cho Tiện ích Chrome, chúng tôi sẽ tiếp tục không cho phép thực thi mã tuỳ ý được lưu trữ từ xa trong tiện ích Chrome. Tuy nhiên, điều này không có nghĩa là chúng tôi không cho phép mọi loại hoạt động thực thi mã động. Chúng tôi vẫn hỗ trợ nhiều lựa chọn để thực thi mã một cách linh động trong các tiện ích Chrome:

H: Tiện ích Manifest V2 của tôi dựa vào webRequestBlocking (không được hỗ trợ trong Manifest V3). Làm cách nào để tiếp tục cung cấp chức năng tương tự trong Manifest V3?
Đáp: Chúng tôi tin rằng hầu hết các trường hợp sử dụng chặn yêu cầu đều có thể được giải quyết bằng API declarativeNetRequest mới. API này có thêm lợi ích là tránh được chi phí hiệu suất của hoạt động giao tiếp giữa các quy trình, thực thi mã trên mọi yêu cầu hoặc yêu cầu quy trình tiện ích đang hoạt động tại thời điểm yêu cầu. Tuy nhiên, đối với các trường hợp sử dụng phức tạp của doanh nghiệp (hoặc giáo dục), tính năng chặn yêu cầu động vẫn được hỗ trợ.

Chúng tôi có bỏ lỡ điều gì không? Hãy cho chúng tôi biết.