Chrome 134 Beta

Rachel Andrew

Veröffentlicht am 5. Februar 2025

Sofern nicht anders angegeben, gelten die folgenden Änderungen für die neueste Chrome-Betaversion für Android, ChromeOS, Linux, macOS und Windows. Weitere Informationen zu den hier aufgeführten Funktionen finden Sie über die bereitgestellten Links oder in der Liste auf ChromeStatus.com. Chrome 134 ist ab dem 5. Februar 2025 als Betaversion verfügbar. Sie können die aktuelle Version für Computer auf Google.com oder für Android im Google Play Store herunterladen.

CSS

In dieser Version werden fünf neue CSS- und UI-Funktionen eingeführt.

CSS-Eigenschaft „dynamic-range-limit“

Ermöglicht es einer Seite, die maximale Helligkeit von HDR-Inhalten zu begrenzen.

Anpassbares <select>-Element

Es ist jetzt möglich, HTML-<select>-Elemente anzupassen. Dazu müssen Sie das neue Verhalten mit dem base-select-Wert appearance aktivieren. Nachdem Sie die Funktion aktiviert haben, können Sie Rich-Content wie Bilder hinzufügen und die Optionen gestalten.

Dialogfeld schließen

Eine der nützlichen Funktionen der Popover API ist das Verhalten beim Schließen durch Klicken auf eine Stelle außerhalb des Popovers. Mit dieser Funktion wird dieselbe Möglichkeit für <dialog> eingeführt. Ein neues closedby-Attribut steuert das Verhalten:

• <dialog closedby=none>: Dialogfelder werden nicht vom Nutzer geschlossen.
• <dialog closedby=closerequest>: Wenn Sie ESC oder einen anderen Schließtrigger drücken, wird das Dialogfeld geschlossen.
• <dialog closedby=any>: Wenn Sie außerhalb des Dialogfelds klicken oder die Esc-Taste drücken, wird das Dialogfeld geschlossen. Das Verhalten entspricht dem von popover=auto.

CSS-Highlight übernehmen

Mit der Funktion „CSS-Highlight übernehmen“ werden die Eigenschaften der CSS-Highlight-Pseudoklassen wie ::selection und ::highlight über die Pseudo-Highlight-Kette und nicht über die Elementkette übernommen. Das Ergebnis ist ein intuitiveres Modell für die Übernahme von Eigenschaften in Hervorhebungen.

Weitere Informationen finden Sie im Blogpost Inheritance changes for CSS selection styling von Stephen Chenney von Igalia.

:has-slotted-Pseudoklasse

Die Pseudoklasse :has-slotted stellt ein Slot-Element mit eingefügten Inhalten wie einem Textknoten oder -element dar. Damit lassen sich Elemente formatieren, je nachdem, ob sie Slot-Fallback-Inhalte verwenden oder nicht.

Web APIs

Attribution Reporting API: Limit für aggregierbare Berichte entfernen, wenn die Triggerkontext-ID nicht null ist

Diese Änderung basiert auf dem Feedback von API-Aufrufern und dem Bedarf, eine höhere Anzahl von Conversion-Ereignissen für bestimmte Nutzerabläufe zu erfassen.

Derzeit können mit der API pro Quellregistrierung nur bis zu 20 aggregierbare Berichte generiert werden. Das ist für Anwendungsfälle, in denen Nutzer einen längeren Weg zurücklegen, einschränkend. Durch diese Änderung wird das Limit für aggregierbare Berichte aufgehoben, wenn eine Triggerkontext-ID als Teil der Registrierung angegeben wird. Die Aufhebung dieses Limits ist nur möglich, wenn die Triggerkontext-ID angegeben ist. In diesem Fall wendet die API eine höhere Rate von Nullberichten an, um zu verhindern, dass websiteübergreifende Informationen über die Anzahl der Berichte weitergegeben werden.

Außerdem unterliegen aggregierbare Berichte weiterhin anderen Einschränkungen, die die Gesamtmenge der messbaren Informationen begrenzen, z. B. dem Budget für L1-Beiträge (65.536) pro Quelle und dem Attributionsratenlimit.

Blob-URL-Partitionierung: Abrufen/Navigation

Als Fortsetzung der Speicherpartitionierung wird die Partitionierung des Blob-URL-Zugriffs nach Speicherschlüssel (Website der obersten Ebene, Frame-Ursprung und das boolesche has-cross-site-ancestor-Attribut) implementiert, mit Ausnahme von Navigationen der obersten Ebene, die nur nach Frame-Ursprung partitioniert bleiben. Dieses Verhalten ähnelt dem, was derzeit sowohl in Firefox als auch in Safari implementiert ist, und gleicht die Verwendung von Blob-URLs mit dem Partitionierungsschema ab, das von anderen Storage APIs im Rahmen der Speicherpartitionierung verwendet wird. Außerdem erzwingt Chrome „noopener“ für Renderer-initiierte Navigationen der obersten Ebene zu Blob-URLs, wenn die entsprechende Website websiteübergreifend mit der Website der obersten Ebene ist, die die Navigation ausführt. Damit entspricht Chrome dem Verhalten in Safari. Die entsprechenden Spezifikationen wurden entsprechend aktualisiert.

Diese Änderung kann vorübergehend rückgängig gemacht werden, indem Sie die Richtlinie PartitionedBlobURLUsage festlegen. Die Richtlinie wird eingestellt, wenn die anderen unternehmensbezogenen Richtlinien zur Speicherpartitionierung eingestellt werden.

Dokumentrichtlinie: expect-no-linked-resources

Mit dem Konfigurationspunkt expect-no-linked-resources in Document-Policy kann ein Dokument dem User-Agent mitteilen, dass er seine Ladereihenfolge besser optimieren soll, z. B. indem er das standardmäßige spekulative Parsing-Verhalten (auch als Preload-Scanner bezeichnet) nicht verwendet.

User-Agents haben das spekulative Parsen von HTML implementiert, um spekulativ Ressourcen abzurufen, die im HTML-Markup vorhanden sind, um das Laden von Seiten zu beschleunigen. Für die überwiegende Mehrheit der Seiten im Web, auf denen Ressourcen im HTML-Markup deklariert sind, ist die Optimierung von Vorteil und die Kosten für die Ermittlung dieser Ressourcen sind ein guter Kompromiss. Die folgenden Szenarien können jedoch zu einem suboptimalen Leistungs-Trade-off im Vergleich zur expliziten Zeit führen, die für das Parsen von HTML zum Bestimmen der abzurufenden untergeordneten Ressourcen aufgewendet wird:

• Seiten, für die im HTML-Code keine Ressourcen deklariert sind.
• Große HTML-Seiten mit minimalen oder keinen Ressourcenlasten, bei denen das Vorabladen von Ressourcen explizit mit anderen verfügbaren Vorablademechanismen gesteuert werden könnte.

Die expect-no-linked-resources-Dokumentrichtlinie weist den User-Agent darauf hin, dass er die Zeit für die Bestimmung solcher untergeordneten Ressourcen optimieren kann.

Explizite Ressourcenverwaltung (asynchron und synchron)

Diese Funktionen beziehen sich auf ein gängiges Muster in der Softwareentwicklung in Bezug auf die Lebensdauer und Verwaltung verschiedener Ressourcen (z. B. Arbeitsspeicher und E/A). Dieses Muster umfasst in der Regel die Zuweisung einer Ressource und die Möglichkeit, kritische Ressourcen explizit freizugeben.

Erweiterung der console.timeStamp API zur Unterstützung von Messungen und Präsentationsoptionen

Diese Funktion erweitert die console.timeStamp() API auf abwärtskompatible Weise, um eine leistungsstarke Methode zum Instrumentieren von Anwendungen und zum Anzeigen von Zeitmessungsdaten im Bereich „Leistung“ in DevTools bereitzustellen.

Mit der API hinzugefügte Zeitachseneinträge können einen benutzerdefinierten Zeitstempel, eine benutzerdefinierte Dauer und benutzerdefinierte Präsentationsoptionen (Track, Swimlane und Farbe) haben.

OffscreenCanvas getContextAttributes

Fügt die getContextAttributes-Schnittstelle aus CanvasRenderingContext2D zu OffscreenCanvasRenderingContext2D hinzu.

Private Aggregation API: Beitragslimits pro Kontext für Shared Storage-Aufrufer

Ermöglicht es Aufrufern von Shared Storage, die Anzahl der Beiträge pro Private Aggregation-Bericht anzupassen.

Mit dieser Funktion können Shared Storage-Aufrufer mit dem neuen Feld maxContributions kontextbezogene Beitragslimits konfigurieren. Anrufer legen dieses Feld fest, um die Standardanzahl der Beiträge pro Bericht zu überschreiben. Sowohl größere als auch kleinere Zahlen sind zulässig. Chrome akzeptiert Werte für maxContributions zwischen 1 und 1.000 (jeweils einschließlich). Größere Werte werden als 1.000 interpretiert.

Aufgrund des Auffüllens ist die Größe der Nutzlast jedes Berichts in etwa proportional zur ausgewählten Anzahl von Beiträgen pro Bericht. Wir gehen davon aus, dass die Kosten für den Betrieb des Aggregation Service steigen, wenn Sie sich für größere Berichte entscheiden.

Aufrufer von Protected Audience sind von dieser Funktion nicht betroffen. Wir planen jedoch, in zukünftigen Funktionen die Möglichkeit hinzuzufügen, die Anzahl der Beiträge für Protected Audience-Berichte anzupassen.

ImageSmoothingQuality in PaintCanvas unterstützen

Unterstützung für das Attribut imageSmoothingQuality in Paint Canvas hinzugefügt. Damit kann ein Webentwickler beim Skalieren von Bildern zwischen Qualität und Leistung wählen. Für imageSmoothingQuality gibt es drei gültige Optionen: low, medium und high.

WebGPU-Untergruppen

Fügt WebGPU die Untergruppenfunktion hinzu. Untergruppenoperationen führen SIMT-Operationen aus, um eine effiziente Kommunikation und gemeinsame Nutzung von Daten zwischen Gruppen von Aufrufen zu ermöglichen. Mit diesen Vorgängen können Anwendungen beschleunigt werden, indem der durch die Kommunikation zwischen Aufrufen verursachte Speicher-Overhead reduziert wird.

Neue Ursprungstests

In Chrome 134 können Sie die folgenden neuen Origin Trials aktivieren.

Digital Credential API

Websites können und erhalten Anmeldedaten von mobilen Wallet-Apps über verschiedene Mechanismen, z. B. benutzerdefinierte URL-Handler und das Scannen von QR-Codes. Mit dieser Funktion können Websites Identitätsinformationen aus Wallets über das IdentityCredential-System von Android anfordern.CredMan Es ist erweiterbar, um mehrere Anmeldedatenformate zu unterstützen (z. B. ISO mDoc und W3C-Nachweis) und die Verwendung mehrerer Wallet-Apps zu ermöglichen. Es werden Mechanismen hinzugefügt, um das Risiko eines missbräuchlichen Einsatzes von Identitäten in der realen Welt im großen Stil zu verringern.

Mit dem Ursprungstest, der in Chrome 134 beginnt, wird die Unterstützung für diese API auf der Desktop-Plattform hinzugefügt. Chrome für den Desktop kommuniziert sicher mit der digitalen Geldbörse auf dem Android-Smartphone, um die angeforderten Anmeldedaten abzurufen.

Einstellung und Entfernung

In dieser Version von Chrome werden die unten aufgeführten Einstellungen und Entfernungen eingeführt. Auf ChromeStatus.com finden Sie Listen mit geplanten, aktuellen und früheren Entfernungen.

In dieser Version von Chrome wird eine Funktion entfernt.

Nicht standardmäßige getUserMedia-Audioeinschränkungen entfernen

Blink unterstützt eine Reihe nicht standardmäßiger Einschränkungen mit dem Präfix goog für getUserMedia aus der Zeit, bevor die Einschränkungen richtig standardisiert wurden.

Die Nutzung ist je nach Einschränkung auf etwa 0,000001% bis 0,0009 % gesunken. Einige der Einschränkungen haben aufgrund von Änderungen am Audio-Capture-Stack für Chromium gar keine Auswirkungen. Aufgrund anderer bevorstehender Änderungen haben bald keine der Einschränkungen mehr Auswirkungen.

Wir gehen nicht davon aus, dass es aufgrund dieser Änderung zu einer größeren Regression kommt. Anwendungen, die diese Einschränkungen verwenden, funktionieren weiterhin, erhalten aber Audio mit den Standardeinstellungen (so, als wären keine Einschränkungen übergeben worden). Sie können zu Standardeinschränkungen migrieren.