Chrome 134 beta

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

Trừ khi có ghi chú khác, các thay đổi sau đây sẽ áp dụng cho bản phát hành mới nhất của kênh beta Chrome dành 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 đang ở giai đoạn thử nghiệm 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 từ Google.com dành cho máy tính hoặc 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 thức, bao gồm cả hình ảnh, cũng như tạo kiểu cho các lựa chọn.

Đóng hộp thoại bằng đèn

Một trong những tính năng thú vị của API Popover là hành vi đóng nhẹ. 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 được đóng do người dùng kích hoạt.
  • <dialog closedby=closerequest>: Thao tác nhấn ESC (hoặc trình kích hoạ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 để đóng hộp thoại. Tương tự như hành vi của popover=auto.

Tính năng kế thừa làm nổi bật CSS

Với tính năng kế thừa làm nổi bật CSS, các lớp giả làm nổi bật CSS, chẳng hạn như ::selection::highlight, kế thừa các thuộc tính của chúng thông qua chuỗi làm nổi bật giả, thay vì 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 điểm nổi bật.

Để tìm hiểu thêm, hãy đọc bài đăng trên blog Thay đổi về tính kế thừa cho kiểu lựa chọn CSS do Stephen Chenney thuộc Igalia viết.

Lớp giả :has-slotted

Lớp giả lập :has-slotted đại diện cho một phần tử khe có nội dung được đặt trong khe, chẳng hạn như một nút hoặc phần tử văn bản. 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 các phần tử đó có đang sử dụng nội dung dự phòng của khung hay không.

API web

Tính năng báo cáo phân bổ: Xoá giới hạn báo cáo tổng hợp khi mã ngữ 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 phương thức 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 nhất định.

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

Ngoài ra, các báo cáo tổng hợp vẫn sẽ chịu sự ràng buộc của các 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à giới hạn tỷ lệ phân bổ.

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

Tiếp nối tính năng Phân vùng bộ nhớ, hãy triển khai tính năng phân vùng quyền truy cập vào URL blob theo Khoá bộ nhớ (trang web cấp cao nhất, nguồn gốc khung và boolean có-đường-lối-tổ-của-nhiều-trang-web), ngoại trừ các thao tác đ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 mà cả Firefox và Safari hiện đang triển khai, đồng thời điều chỉnh việc sử dụng URL Blob với lược đồ phân vùng mà các API bộ nhớ khác sử dụng trong quá trình Phân vùng bộ nhớ. Ngoài ra, Chrome sẽ thực thi noopener trên các thao tác đ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 nằm trên nhiều trang web với trang web cấp cao nhất thực hiện thao tác điều hướng. Điều này giúp Chrome phù hợp với hành vi tương tự trong Safari và các thông số kỹ thuật 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 Chính sách tài liệu cho phép tài liệu gợi ý cho tác nhân người dùng để tối ưu hoá trình tự tải của tài liệu hiệu quả hơn, chẳng hạn như không sử dụng hành vi phân tích cú pháp dự đoán mặc định (còn gọi là trình quét tải trước).

Các Tác nhân người dùng đã triển khai tính năng phân tích cú pháp dự đoán HTML để tìm nạp dự đ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á sẽ mang lại lợi ích và chi phí trả để xác định các tài nguyên đó là một sự đánh đổi hợp lý. Tuy nhiên, các tình huống sau đây có thể dẫn đến hiệu suất không tối ưu so với thời gian rõ ràng để phân tích cú pháp HTML nhằm xác định tài nguyên phụ cần tìm nạp:

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

Chính sách tài liệu expect-no-linked-resources gợi ý cho Tác nhân người dùng rằng tác nhân này 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ộ)

Các 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 hoạt động 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 tài nguyên quan trọng một cách rõ rà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 phương thức hiệu suất cao cho việc đo lường các ứng dụng và hiển thị dữ liệu thời gian cho bảng điều khiển Hiệu suất trong DevTools.

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 tuỳ chọn trình bày tuỳ chỉnh (đường đua, luồ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 ngữ cảnh cho phương thức gọi Shared Storage

Cho phép phương thức gọi Bộ nhớ dùng chung tuỳ chỉnh số lượt đóng góp trên mỗi báo cáo Tổng hợp riêng tư.

Tính năng này cho phép phương thức gọi Bộ nhớ dùng chung định cấu hình các giới hạn đóng góp theo ngữ cảnh bằng một trường mới là maxContributions. Phương thức gọi đặt trường này để ghi đè số lượng đóng góp mặc định trên mỗi báo cáo. Cả số 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; các giá trị lớn hơn sẽ được diễn giải là 1000.

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

Tính năng này sẽ không ảnh hưởng đến các phương thức gọi Protected Audience. Tuy nhiên, chúng tôi dự định sẽ hỗ trợ thêm tính năng tuỳ chỉnh số lượng nội dung đóng góp cho báo cáo Protected Audience trong các tính năng trong tương lai.

Hỗ trợ ImageSmoothingQuality trong PaintCanvas

Thêm tính năng hỗ trợ cho thuộc tính imageSmoothingQuality trên Paint Canvas. API này cho phép nhà phát triển web chọn chất lượng thay vì đánh đổi hiệu suất khi điều chỉnh tỷ lệ hình ảnh. Có 3 tuỳ 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 của 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ể sử 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 mới về nguồn gốc sau.

API thông tin xác thực kỹ thuật số

Các trang web hiện có thể và đang nhận thông tin xác thực từ các ứng dụng ví di động thông qua nhiều cơ chế, 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 cách sử dụ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 xác thực (ví dụ: ISO mDoc và thông tin xác thực có thể kiểm tra 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.

Bản dùng thử theo nguồn gốc bắt đầu từ Chrome 134 sẽ 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 một cách an toàn với ví kỹ thuật số trên điện thoại Android để tìm nạp thông tin xác thực được yêu cầu.

Ngừng sử dụng và xoá

Phiên bản Chrome này giới thiệu các tính năng ngừng hoạt động và bị xoá được liệt kê bên dưới. Hãy truy cập vào ChromeStatus.com để xem danh sách các tính năng dự kiến ngừng hoạt động, các tính năng hiện đã ngừng hoạt động và các tính năng đã bị xoá trước đó.

Bản phát hành Chrome này xoá một tính năng.

Xoá các quy tắc ràng buộc âm thanh getUserMedia không chuẩn

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

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

Chúng tôi không dự kiến sẽ có bất kỳ sự hồi quy lớn nào do thay đổi này. Các ứng dụng sử dụng các quy tắc 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ó quy tắc ràng buộc nào được truyền). Họ có thể chọn di chuyển sang các quy tắc ràng buộc tiêu chuẩn.