Chrome 134 beta

Xuất bản: Ngày 5 tháng 2 năm 2025

Trừ phi có ghi chú khác, các thay đổi sau đây áp dụng cho bản phát hành mới nhất của kênh Chrome beta cho Android, ChromeOS, Linux, macOS và Windows. Tìm hiểu thêm về các tính năng được liệt kê tại đây thông qua các đường liên kết được cung cấp hoặc trong danh sách trên ChromeStatus.com. Chrome 134 là phiên bản beta kể từ ngày 5 tháng 2 năm 2025. Bạn có thể tải phiên bản mới nhất xuống trên Google.com cho máy tính hoặc trên Cửa hàng Google Play trên Android.

CSS

Bản phát hành này bổ sung 5 tính năng mới về CSS và giao diện người dùng.

Thuộc tính dynamic-range-limit của CSS

Cho phép một trang giới hạn độ sáng tối đa của nội dung HDR.

Phần tử <select> có thể tuỳ chỉnh

Thêm khả năng tuỳ chỉnh các phần tử <select> HTML bằng cách chọn sử dụng hành vi mới với giá trị base-selectappearance. Sau khi chọn sử dụng, bạn có thể thêm nội dung đa dạng (bao gồm cả hình ảnh) và tạo kiểu cho các lựa chọn.

Đóng hộp thoại bằng cách nhấn vào vùng sáng

Một trong những tính năng hay của Popover API là hành vi đóng nhanh. Tính năng này mang lại khả năng tương tự cho <dialog>. Thuộc tính closedby mới kiểm soát hành vi:

  • <dialog closedby=none>: Không có hộp thoại nào bị đóng do người dùng kích hoạt.
  • <dialog closedby=closerequest>: Nhấn ESC (hoặc một nút đóng khác) sẽ đóng hộp thoại.
  • <dialog closedby=any>: Nhấp vào bên ngoài hộp thoại hoặc nhấn phím ESC sẽ đóng hộp thoại. Tương tự như hành vi của popover=auto.

CSS highlight inheritance (Kế thừa điểm đánh dấu CSS)

Với tính năng kế thừa điểm đánh dấu CSS, các lớp giả điểm đánh dấu CSS (chẳng hạn như ::selection::highlight) sẽ kế thừa các thuộc tính của chúng thông qua chuỗi điểm đánh dấu giả, chứ không phải chuỗi phần tử. Kết quả là một mô hình trực quan hơn để kế thừa các thuộc tính trong phần làm nổi bật.

Để tìm hiểu thêm, hãy đọc bài đăng trên blog Các thay đổi về tính kế thừa đối với kiểu chọn CSS do Stephen Chenney của Igalia viết.

:has-slotted lớp giả

Lớp giả :has-slotted đại diện cho một phần tử khe cắm có nội dung được đưa vào khe cắm, chẳng hạn như một nút văn bản hoặc phần tử. Bạn có thể dùng thuộc tính này để tạo kiểu cho các phần tử dựa trên việc chúng có đang dùng nội dung dự phòng của vùng hay không.

Web API

Tính năng Báo cáo phân bổ: Xoá giới hạn Báo cáo có thể tổng hợp khi mã nhận dạng bối cảnh của điều kiện kích hoạt không phải là giá trị rỗng

Thay đổi này dựa trên ý kiến phản hồi của người gọi API và nhu cầu đo lường số lượng sự kiện chuyển đổi cao hơn cho một số luồng người dùng.

Hiện tại, API có giới hạn cho phép tạo tối đa 20 báo cáo có thể tổng hợp cho mỗi lần đăng ký nguồn. Điều này hạn chế các trường hợp sử dụng khi người dùng có thể có hành trình dài hơn. Thay đổi này sẽ xoá giới hạn báo cáo có thể tổng hợp khi mã nhận dạng bối cảnh của điều kiện kích hoạt được cung cấp trong quá trình đăng ký. Việc xoá giới hạn này chỉ được thực hiện khi bạn chỉ định mã nhận dạng bối cảnh của điều kiện kích hoạt, vì khi bạn chỉ định mã nhận dạng này, API sẽ áp dụng tỷ lệ báo cáo rỗng cao hơn. Điều này giúp bảo vệ khỏi tình trạng rò rỉ thông tin trên nhiều trang web thông qua số lượng báo cáo.

Ngoài ra, các báo cáo có thể tổng hợp vẫn sẽ bị ràng buộc bởi những giới hạn khác hạn chế tổng lượng thông tin có thể đo lường, chẳng hạn như ngân sách đóng góp L1 (65.536) cho mỗi nguồn và hạn mức tốc độ phân bổ.

Phân vùng URL Blob: Tìm nạp/Điều hướng

Tiếp tục Phân vùng bộ nhớ, triển khai phân vùng quyền truy cập URL Blob theo Khoá lưu trữ (trang web cấp cao nhất, nguồn gốc khung và giá trị boolean has-cross-site-ancestor), ngoại trừ các yêu cầu điều hướng cấp cao nhất sẽ chỉ được phân vùng theo nguồn gốc khung. Hành vi này tương tự như hành vi hiện được cả Firefox và Safari triển khai, đồng thời điều chỉnh việc sử dụng URL Blob theo lược đồ phân vùng mà các API lưu trữ khác sử dụng trong Phân vùng bộ nhớ. Ngoài ra, Chrome sẽ thực thi noopener đối với các yêu cầu điều hướng ở cấp cao nhất do trình kết xuất khởi tạo đến URL Blob, trong đó trang web tương ứng là từ nhiều trang web so với trang web cấp cao nhất thực hiện yêu cầu điều hướng. Điều này giúp Chrome có hành vi tương tự như Safari và các thông số kỹ thuật có liên quan đã được cập nhật để phản ánh những thay đổi này.

Bạn có thể tạm thời huỷ thay đổi này bằng cách đặt chính sách PartitionedBlobURLUsage. Chính sách này sẽ không được dùng nữa khi các chính sách doanh nghiệp khác liên quan đến việc phân vùng bộ nhớ không được dùng nữa.

Document-Policy: expect-no-linked-resources

Điểm cấu hình expect-no-linked-resources trong Document-Policy cho phép một gợi ý tài liệu cho tác nhân người dùng để tối ưu hoá tốt hơn trình tự tải, chẳng hạn như không sử dụng hành vi phân tích cú pháp suy đoán mặc định (còn được gọi là trình quét tải trước).

Tác nhân người dùng đã triển khai tính năng phân tích cú pháp suy đoán của HTML để tìm nạp suy đoán các tài nguyên có trong mã đánh dấu HTML, nhằm tăng tốc độ tải trang. Đối với phần lớn các trang trên Web có tài nguyên được khai báo trong mã đánh dấu HTML, việc tối ưu hoá là có lợi và chi phí phải trả khi xác định các tài nguyên đó là một sự đánh đổi hợp lý. Tuy nhiên, các trường hợp sau đây có thể dẫn đến sự đánh đổi hiệu suất không tối ưu so với thời gian rõ ràng đã dành để phân tích cú pháp HTML nhằm xác định các tài nguyên phụ cần tìm nạp:

  • Những trang không có tài nguyên nào được khai báo trong HTML.
  • Các trang HTML lớn có mức tải tài nguyên tối thiểu hoặc không tải tài nguyên nào có thể kiểm soát rõ ràng các tài nguyên tải trước bằng cách sử dụng các cơ chế tải trước khác hiện có.

expect-no-linked-resources Document-Policy gợi ý cho User Agent rằng nó có thể chọn tối ưu hoá thời gian dành cho việc xác định tài nguyên phụ như vậy.

Quản lý tài nguyên rõ ràng (không đồng bộ và đồng bộ)

Những tính năng này giải quyết một mẫu phổ biến trong quá trình phát triển phần mềm liên quan đến thời gian tồn tại và việc quản lý nhiều tài nguyên (ví dụ: bộ nhớ và I/O). Mẫu này thường bao gồm việc phân bổ tài nguyên và khả năng giải phóng rõ ràng các tài nguyên quan trọng.

Mở rộng API console.timeStamp để hỗ trợ các lựa chọn đo lường và trình bày

Tính năng này mở rộng API console.timeStamp() theo cách tương thích ngược để cung cấp một phương thức hiệu suất cao nhằm đo lường các ứng dụng và hiển thị dữ liệu về thời gian cho bảng điều khiển Hiệu suất trong Công cụ cho nhà phát triển.

Các mục thời gian được thêm bằng API có thể có dấu thời gian, thời lượng và các lựa chọn trình bày tuỳ chỉnh (đường chạy, làn đường và màu sắc).

OffscreenCanvas getContextAttributes

Thêm giao diện getContextAttributes từ CanvasRenderingContext2D vào OffscreenCanvasRenderingContext2D.

Private Aggregation API: giới hạn đóng góp theo bối cảnh cho các phương thức gọi Shared Storage

Cho phép các đối tượng gọi Shared Storage tuỳ chỉnh số lượt đóng góp cho mỗi báo cáo Private Aggregation.

Tính năng này cho phép các đối tượng gọi Shared Storage định cấu hình giới hạn đóng góp theo ngữ cảnh bằng một trường mới là maxContributions. Người gọi đặt trường này để ghi đè số lượng đóng góp mặc định cho mỗi báo cáo – cả số lượng lớn hơn và nhỏ hơn đều được phép. Chrome sẽ chấp nhận các giá trị maxContributions từ 1 đến 1000 (tính cả 2 giá trị đầu cuối); các giá trị lớn hơn sẽ được hiểu là 1000.

Do khoảng đệm, kích thước của tải trọng trong mỗi báo cáo sẽ tỷ lệ thuận với số lượng đóng góp đã chọn cho mỗi báo cáo. Chúng tôi dự kiến việc chọn sử dụng các báo cáo lớn hơn sẽ làm tăng chi phí vận hành Aggregation Service.

Các lệnh gọi Protected Audience API sẽ không bị ảnh hưởng bởi tính năng này. Tuy nhiên, chúng tôi dự định sẽ hỗ trợ tuỳ chỉnh số lượng lượt đóng góp cho báo cáo Protected Audience trong các tính năng sau này.

Hỗ trợ ImageSmoothingQualityPaintCanvas

Thêm tính năng hỗ trợ cho thuộc tính imageSmoothingQuality trên Canvas vẽ. API này cho phép nhà phát triển web chọn chất lượng so với sự đánh đổi hiệu suất khi điều chỉnh tỷ lệ hình ảnh. Có 3 lựa chọn hợp lệ cho imageSmoothingQuality: low, mediumhigh.

Nhóm con WebGPU

Thêm chức năng nhóm con vào WebGPU. Các thao tác trên nhóm con thực hiện các thao tác SIMT để cung cấp khả năng giao tiếp và chia sẻ dữ liệu hiệu quả giữa các nhóm lệnh gọi. Bạn có thể dùng các thao tác này để tăng tốc ứng dụng bằng cách giảm mức hao tổn bộ nhớ do hoạt động giao tiếp giữa các lệnh gọi gây ra.

Bản dùng thử theo nguyên gốc mới

Trong Chrome 134, bạn có thể chọn tham gia các thử nghiệm nguồn gốc mới sau đây.

Digital Credential API

Các trang web có thể và thực sự lấy thông tin đăng nhập từ các ứng dụng ví di động thông qua nhiều cơ chế hiện nay, chẳng hạn như trình xử lý URL tuỳ chỉnh và tính năng quét mã QR. Tính năng này cho phép các trang web yêu cầu thông tin nhận dạng từ ví bằng hệ thống IdentityCredential CredMan của Android. API này có thể mở rộng để hỗ trợ nhiều định dạng thông tin đăng nhập (ví dụ: ISO mDoc và thông tin đăng nhập có thể xác minh của W3C) và cho phép sử dụng nhiều ứng dụng ví. Chúng tôi đang bổ sung các cơ chế để giúp giảm nguy cơ lạm dụng danh tính ngoài đời thực trên quy mô hệ sinh thái.

Thử nghiệm nguồn bắt đầu trong Chrome 134 sẽ bổ sung tính năng hỗ trợ API này trên nền tảng máy tính, trong đó Chrome trên máy tính sẽ giao tiếp an toàn với ví kỹ thuật số trên điện thoại Android để tìm nạp thông tin đăng nhập được yêu cầu.

Bản không dùng nữa và xoá

Phiên bản Chrome này giới thiệu các tính năng không dùng nữa và bị xoá như được liệt kê bên dưới. Hãy truy cập ChromeStatus.com để xem danh sách các tính năng dự kiến sẽ không dùng nữa, các tính năng hiện không dùng nữa và các tính năng đã bị xoá trước đây.

Bản phát hành Chrome này sẽ loại bỏ một tính năng.

Xoá các hạn chế âm thanh getUserMedia không theo tiêu chuẩn

Blink hỗ trợ một số ràng buộc không theo tiêu chuẩn có tiền tố goog cho getUserMedia từ một thời điểm trước khi các ràng buộc được chuẩn hoá đúng cách.

Mức sử dụng đã giảm đáng kể xuống từ 0,000001% đến 0,0009% (tuỳ thuộc vào hạn chế) và một số trong số đó thậm chí không có tác dụng do những thay đổi trong ngăn xếp ghi âm của Chromium. Sắp tới, không có thay đổi nào trong số này có hiệu lực do những thay đổi sắp tới khác.

Chúng tôi không dự kiến sẽ có bất kỳ lỗi nào nghiêm trọng do thay đổi này gây ra. Các ứng dụng sử dụng những ràng buộc này sẽ tiếp tục hoạt động, nhưng sẽ nhận được âm thanh với chế độ cài đặt mặc định (như thể không có ràng buộc nào được truyền). Họ có thể chọn di chuyển sang các ràng buộc tiêu chuẩn.