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

Gần đây, chúng tôi đã thông báo về các thay đổi đối với tiến trình ngừng sử dụng Manifest V2. Mặc dù vẫn cam kết chắc chắn với Manifest V3, nhưng chúng tôi xác nhận rằng chúng tôi vẫn còn nhiều việc cần làm.

  • Trước khi công bố tiến trình mới cho việc ngừng sử dụng, chúng tôi đã giải quyết xong các lỗ hổng về nền tảng được ưu tiên và đóng các lỗi nghiêm trọng được nêu trên trang này.
  • Chúng tôi đã cho các nhà phát triển thời gian xây dựng, bằng cách đảm bảo ít nhất 6 tháng giữa thời điểm thông báo về tiến trình cho đến thời điểm thử nghiệm đang chờ xử lý việc ngừng hỗ trợ Manifest V2.

Thu hẹp khoảng cách với nền tảng

Chúng tôi cam kết sẽ thu hẹp khoảng cách sau đây trước khi công bố tiến trình mới cho việc ngừng sử dụng Manifest V2:

Chúng tôi thu thập sự cố dựa trên ý kiến phản hồi của đối tác, báo cáo lỗi và nhà phát triển. Chúng tôi sẽ tiếp tục nỗ lực không ngừng nhằm cải thiện độ ổn định và hiệu suất tổng thể của nền tảng tiện ích.

Hiện chưa có vấn đề nào chưa được xử lý được coi là khoảng trống nghiêm trọng trên nền tảng.

Các vấn đề sau đã được giải quyết gần đây:

  1. Hỗ trợ Xử lý tệp trên ChromeOS để thay thế cho chrome.fileBrowserHandler [Chrome 120].
  2. Hỗ trợ User Script: Cho phép đăng ký tập lệnh nội dung bằng mã tuỳ ý bằng userScripts API mới [Chrome 120].
  3. Thêm trình chạy dịch vụ mạnh mẽ duy trì cho một số hoạt động nhất định mất hơn 5 phút.
    • Đã thêm vào Chrome 116 dành cho permissions.request(), desktopCapture.chooseDesktopMedia(), identity.launchWebAuthFlow() và management.uninstall().
    • Đã thêm vào Chrome 118 cho chrome.debugger
  4. Tăng số lượng tập hợp quy tắc tĩnh và được bật cho Yêu cầu ròng khai báo (DNR). Số bộ quy tắc tĩnh đang bật tăng từ 10 lên 50 và tổng số bộ quy tắc tĩnh 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ợ thêm nhiều lý do sử dụng tài liệu ngoài màn hình. Thêm GEOLOCATION vào Chrome 116.
  6. Cải thiện dịch vụ hỗ trợ dành cho API chrome.tabCapture [Chrome 116]:
    • Hỗ trợ gọi getMediaStreamId() từ một trình chạy dịch vụ.
    • Hỗ trợ lấy MediaStream từ mã luồng trong 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ó kết nối WebSocket đ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ợ Nhân viên dịch vụ liên tục không?
Đáp: Một trong những lý do chính khiến bạn 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 dựa trên sự kiện có hiệu quả bộ nhớ cao hơn, 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ợ nhân viên dịch vụ liên tục. Tuy nhiên, để giải quyết các nhu cầu cụ thể của nhà phát triển tiện ích, chúng tôi đang tiếp tục thực hiện nhiều cải tiến cho nhân viên 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 thời gian hoạt động của trình chạy dịch vụ.
  • Các trường hợp sử dụng đã chọn, chẳng hạn như nhắn tin gốc sẽ giúp trình thực thi dịch vụ tiện ích tồn tại lâu hơn 5 phút.

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

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 các Tiện ích của 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 các tiện ích của 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 hình thức thực thi mã động. Chúng tôi vẫn hỗ trợ nhiều tuỳ chọn tự động thực thi mã trong tiện ích của Chrome:

Hỏi: 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 declarativeNetRequest API mới. API này có thêm lợi ích là tránh được hao tổn hiệu suất khi giao tiếp liên quy trình, thực thi mã trên mọi yêu cầu hoặc đòi hỏi quy trình gia hạn 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? Vui lòng cho chúng tôi biết.