Leuffen.deBlog

News

Chrome 153: Browser-Schaltflächen für Kamera- und Mikrofonzugriff, gekoppelte Iteratoren und ein XML-Parser in Rust

Chrome 153 bringt browserkontrollierte HTML-Elemente für Kamera und Mikrofon, neue JavaScript-Methoden zum parallelen Durchlaufen von Daten und einen in Rust geschriebenen XML-Parser.

Veröffentlicht am
Veröffentlicht von
Redaktion Blog Leuffen.de
Geprüft von
Clara Winter

Chrome 153 ist die am 8. September veröffentlichte stabile Version von Googles Webbrowser. Die greifbarste Neuerung sind <camera> und <microphone>: zwei HTML-Elemente, mit denen eine Webseite gezielt um Zugriff auf Kamera oder Mikrofon bitten kann, ohne die entscheidende Schaltfläche selbst zu zeichnen.

Die gemeinsame Linie des Releases ist unspektakulär und sinnvoll: Einige Aufgaben, die Anwendungen bisher selbst zusammensetzen mussten, wandern in die Plattform. Das gilt für Berechtigungsoberflächen ebenso wie für das parallele Durchlaufen von Daten. Ein Freibrief für den sofortigen Einsatz in allen Browsern ist das natürlich nicht. Das Web bleibt das Web.

Der Browser zeichnet die Schaltfläche

Die neuen Capability-Elemente sind deklarative, vom Browser dargestellte Bedienelemente für den Zugriff auf genau eine Gerätefunktion. <camera> fordert Videoaufnahme an, <microphone> Audioaufnahme. Erst ein bewusster Klick des Nutzers darf die Berechtigungsabfrage auslösen oder einen Datenstrom starten. Die Oberfläche ist streng durch den Browser vorgegeben. Eine Seite kann damit nicht einfach eine beliebig gestaltete Schaltfläche über einen sensiblen Berechtigungsdialog legen.

Bestehender Code für MediaDevices.getUserMedia() kann deshalb nicht verschwinden. Diese JavaScript-Schnittstelle fordert Kamera- oder Mikrofonzugriff programmgesteuert an und bleibt als Rückfallweg für andere Browser nötig. Wer die neuen Elemente einsetzt, sollte sie als progressive Erweiterung behandeln und den bisherigen Ablauf behalten, solange die Browserunterstützung nicht zum eigenen Nutzerbestand passt.

zip() beendet die Indexgymnastik

Ein Iterator ist in JavaScript ein Objekt, das Werte einer Folge nacheinander liefert, ohne zwingend vorher ein vollständiges Array anzulegen. Chrome 153 unterstützt nun Iterator.zip() und Iterator.zipKeyed(). Beide Methoden rücken mehrere Folgen gemeinsam vor. zip() endet standardmäßig, sobald die kürzeste Eingabe erschöpft ist; zipKeyed() liefert statt Wertepaaren Objekte mit benannten Feldern.

function pairArraysByPosition(left, right) {
  if (typeof globalThis.Iterator?.zip === "function") {
    return Array.from(Iterator.zip([left, right]));
  }

  const length = Math.min(left.length, right.length);

  return left
    .slice(0, length)
    .map((value, index) => [value, right[index]]);
}

pairArraysByPosition(["Chrome", "Firefox", "Safari"], [153, 151]);
// [["Chrome", 153], ["Firefox", 151]]

Der Rückfallweg ist bewusst auf Arrays begrenzt und bildet nur den Standardmodus shortest nach. Anders als ein Iterator hält er alle Werte bereits im Speicher. Wer allgemeine oder sogar unendliche Folgen, longest, eigene Füllwerte oder strict verwendet, braucht einen passenden Iterator-Fallback oder eine Bibliothek. Progressive Enhancement bedeutet nicht, dass man nur den hübschen Zweig testet.

Der XML-Parser wird intern ausgetauscht

Chrome 153 verwendet für mehrere XML-Szenarien einen in Rust geschriebenen Parser. Ein XML-Parser ist die Browserkomponente, die strukturierte XML-Dokumente einliest und in ein verarbeitbares Dokumentmodell übersetzt. Rust ist eine Programmiersprache, die zahlreiche Speicherfehler bereits durch ihr Typsystem verhindert.

Der neue Parser wird nur in Szenarien ohne XSLT verwendet. Dazu gehören DOMParser, responseXML von XMLHttpRequest sowie das direkte oder eingebettete Laden eigenständiger SVG-Dateien. XSLT ist eine Sprache zur Umwandlung von XML-Dokumenten und wird von Chrome bereits separat zurückgebaut. Anwendungen mit ungewöhnlichen XML- oder SVG-Eingaben sollten ihre Tests unter Chrome 153 laufen lassen. „Kompatibel“ ist eine Zusage; ein Integrationstest ist eine Feststellung.

Was noch nicht stabil ist

Die Kombinationen overflow: auto clip, overflow: scroll clip und ähnliche einachsige Scroll-Container tauchen prominent in der Chrome-Zusammenfassung auf. Sie gehören in Chrome 153 jedoch ausdrücklich noch nicht zum Stable-Kanal, sondern stehen ohne Flag nur in Beta, Dev und Canary zum Testen bereit.

Mehrere APIs aus Googles Privacy-Sandbox-Programm – darunter Protected Audience, Related Website Sets, Shared Storage und Attribution Reporting – sind laut Release Notes zur Einstellung und Entfernung vorgesehen. Die Dokumentation nennt dort aber keinen verbindlichen Abschalttermin. Das ist ein Migrationssignal, keine bereits vollzogene Entfernung.

Für Chrome 153 ergibt sich damit eine nüchterne Reihenfolge: die neuen Berechtigungselemente und Iterator-Methoden in kompatiblen Umgebungen erproben, vorhandene Rückfallwege behalten, XML- und SVG-Tests laufen lassen und bei den angekündigten Entfernungen erst dann einen Kalendertermin eintragen, wenn Google selbst einen nennt.

Quellen

Quellenstand: 9. September 2026.