Wycofania i usuwania interfejsów API w Chrome 50

W prawie każdej wersji Chrome wprowadzamy wiele aktualizacji i ulepszeń dotyczących produktu, jego wydajności, a także możliwości platformy internetowej.

W Chrome 50 (szacowana data wersji beta: 10–17 marca) wprowadzono kilka zmian. Ta lista może ulec zmianie w każdej chwili.

Wycofanie metody AppCache w niebezpiecznych kontekstach

W skrócie: aby utrudnić ataki typu cross-site scripting, wycofujemy obsługę AppCache w przypadku niezabezpieczonych źródeł. Spodziewamy się, że w Chrome 52 będzie działać tylko w przypadku źródeł, które udostępniają treści przez HTTPS.

Intend to Remove | Chromestatus Tracker | Chromium Bug

AppCache to funkcja, która umożliwia trwały dostęp offline do źródła. Jest to skuteczne podwyższenie uprawnień w przypadku ataku typu cross-site scripting. W ramach szerszego projektu usuwania zaawansowanych funkcji w niebezpiecznych źródłach danych.

Chrome usuwa ten wektor ataku, zezwalając na niego tylko przez HTTPS. W Chrome 50 wycofujemy obsługę protokołu HTTP, a w Chrome 52 planujemy ją całkowicie usunąć.

Document.defaultCharset został usunięty

TL;DR: document.defaultCharset został usunięty, aby poprawić zgodność ze specyfikacją.

Chcę usunąć | Chromestatus Tracker | CRBug Issue

W Chrome 49 document.defaultCharset, które zostało wycofane, jest właściwością tylko do odczytu, która zwraca domyślne kodowanie znaków systemu użytkownika na podstawie jego ustawień regionalnych. Nie zalecamy zachowywania tej wartości ze względu na sposób, w jaki przeglądarki korzystają z informacji o kodowaniu znaków w odpowiedzi HTTP lub w metatagu umieszczonym na stronie.

Zamiast tego użyj wartości document.characterSet, aby uzyskać pierwszą wartość określoną w nagłówku HTTP. Jeśli nie ma takiego atrybutu, zostanie użyta wartość określona w atrybucie charset elementu <meta> (np. <meta charset="utf-8">). Jeśli żadna z tych wartości nie jest dostępna, atrybut document.characterSet będzie zawierał ustawienie systemu użytkownika.

Więcej informacji o przyczynach, dla których nie chcemy specyfikować tego w specyfikacji, znajdziesz w tym wątku na GitHubie.

TL;DR: usuń obsługę wartości subresource atrybutu rel w atrybucie HTMLLinkElement.

Intend to Remove | Chromestatus Tracker | Chromium Bug

Celem atrybutu subresource w elementie <link> było wstępne wczytanie zasobu w czasie bezczynności przeglądarki. Po pobraniu strony przeglądarka może wstępnie pobrać zasoby, takie jak inne strony, aby po ich żądaniu przez użytkowników można było po prostu pobrać je z pamięci podręcznej przeglądarki.

Atrybut subresource miał wiele problemów. Po pierwsze, nigdy nie działała zgodnie z oczekiwaniami. Zasoby, do których odwołuje się kod, zostały pobrane z niskim priorytetem. Atrybut ten nigdy nie został zaimplementowany w żadnej przeglądarce innej niż Chrome. Implementacja w Chrome zawierała błąd, który powodował pobieranie zasobów dwa razy.

Deweloperzy, którzy chcą zwiększyć wygodę użytkowników dzięki wstępnemu wczytywaniu treści, mają do dyspozycji kilka opcji. Najbardziej elastyczne jest utworzenie elementu workera usługi, który będzie korzystać z wstępnego buforowania i interfejsu Caches API. Dodatkowe rozwiązania obejmują inne wartości atrybutu rel, w tym preconnect, prefetch, preload i prerender. Niektóre z tych opcji są eksperymentalne i mogą nie być obsługiwane powszechnie.

Usuwanie niepewnych wersji TLS

TL;DR: usuń mechanizm wymuszania korzystania przez serwery z mniej bezpiecznych lub niezabezpieczonych wersji protokołu TLS.

Intend to Remove | Chromestatus Tracker | Chromium Bug

Protokół Transport Layer Security (TLS) obsługuje mechanizm negocjowania wersji, co umożliwia wprowadzanie nowych wersji TLS bez zakłócania zgodności. Niektóre serwery były tak zaimplementowane, że przeglądarki musiały używać niezabezpieczonych punktów końcowych jako awaryjnych. W związku z tym atakujący mogą zmusić każdą witrynę (nie tylko te z nieprawidłową konfiguracją) do negocjowania słabszych wersji protokołu TLS.

Witryny, których dotyczy problem, nie będą mogły się połączyć z ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION. Administratorzy powinni zadbać o to, aby oprogramowanie serwera było aktualne. Jeśli problem nie został rozwiązany, skontaktuj się z dostawcą oprogramowania serwera, aby sprawdzić, czy jest dostępna poprawka.

Usuń KeyboardEvent.prototype.keyLocation

Podsumowanie: usuń niepotrzebny alias atrybutu Keyboard.prototype.location.

Intend to Remove | Chromestatus Tracker | Chromium Bug

Ten atrybut to po prostu alias atrybutu Keyboard.prototype.location, który umożliwia rozróżnienie klawiszy znajdujących się w różnych miejscach na klawiaturze. Oba atrybuty pozwalają na przykład deweloperom odróżniać 2 przyciski Enter na rozszerzonej klawiaturze.

Metody RTCPeerConnection wymagają obsługi błędów i sukcesów

TL;DR: metody WebRTC createOffer() i createAnswer() WebRTC wymagają teraz zarówno obsługi błędów, jak i obsługi powodzenia. Wcześniej można było wywoływać te metody tylko z obsługą sukcesu. Takie użycie zostało wycofane.

Intend to Remove | Chromestatus Tracker | Chromium Bug

W Chrome 49 dodaliśmy ostrzeżenie, jeśli wywołujesz funkcję setLocalDescription() lub setRemoteDescription() bez podania obsługi błędów. Od wersji 50 Chrome argument handler jest obowiązkowy.

Jest to część przygotowań do wprowadzenia obietnic dotyczących tych metod, zgodnie z wymaganiami specyfikacji WebRTC.

Oto przykład z demo RTCPeerConnection w WebRTC (main.js, wiersz 126):

    function onCreateOfferSuccess(desc) {
      pc1.setLocalDescription(desc, function() {
         onSetLocalSuccess(pc1);
      }, onSetSessionDescriptionError);
      pc2.setRemoteDescription(desc, function() {
        onSetRemoteSuccess(pc2);
      }, onSetSessionDescriptionError);
      pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
    }

Pamiętaj, że zarówno setLocalDescription(), jak i setRemoteDescription() mają metodę obsługi błędów. Starsze przeglądarki, które oczekują tylko obsługi powodzenia, po prostu zignorują argument obsługi błędu, jeśli jest obecny. Wywołanie tego kodu w starszej przeglądarce nie spowoduje wyjątku.

W przypadku produkcyjnych aplikacji WebRTC zalecamy ogólnie używanie adapter.js, czyli shimu obsługiwanego przez projekt WebRTC, aby odizolować aplikacje od zmian specyfikacji i różnic w prefiksach.

Zdarzenie XMLHttpRequestProgressEvent nie jest już obsługiwane

TL;DR: interfejs XMLHttpRequestProgressEvent zostanie usunięty wraz z atrybutami position i totalSize.

Intend to Remove | Chromestatus Tracker | Chromium Bug

To zdarzenie istniało, aby obsługiwać właściwości zgodności Gecko positiontotalSize. W Mozilla 22 wycofano obsługę tych trzech formatów, a ich funkcje zostały już dawno zastąpione przez ProgressEvent.

     var progressBar = document.getElementById("p"),
          client = new XMLHttpRequest()
      client.open("GET", "magical-unicorns")
      client.onprogress = function(pe) {
        if(pe.lengthComputable) {
          progressBar.max = pe.total
          progressBar.value = pe.loaded
        }
      }

Usuwanie rozszerzeń zaszyfrowanych multimediów z prefiksem

Podsumowanie: rozszerzenia zaszyfrowanych multimediów z prefiksem zostały usunięte na rzecz zastępnika bez prefiksu, który jest zgodny ze specyfikacją.

Intend to Remove | Chromestatus Tracker | Chromium Bug

W Chrome 42 udostępniliśmy wersję bez prefiksu rozszerzeń szyfrowanych multimediów opartą na specyfikacji. Ten interfejs API służy do znajdowania, wybierania i interakcji z systemami zarządzania prawami cyfrowymi na potrzeby HTMLMediaElement.

Minęło już prawie rok. Ponieważ wersja bez prefiksu ma więcej funkcji niż wersja z prefiksem, nadszedł czas, aby usunąć wersję z prefiksem interfejsu API.

Usuwanie obsługi właściwości SVGElement.offset

TL;DR: właściwości offset dla SVGElement zostały usunięte na rzecz bardziej obsługiwanych właściwości w HTMLElement.

Intend to Remove | Chromestatus Tracker | Chromium Bug

Właściwości offset są od dawna obsługiwane przez HTMLElement i SVGElement, ale Gecko i Edge obsługują je tylko w HTMLElement. Aby zwiększyć spójność między przeglądarkami, te właściwości zostały wycofane w Chrome 48 i są obecnie usuwane.

Chociaż równoważne właściwości są częścią interfejsu HTMLElement, deweloperzy, którzy szukają alternatywy, mogą też użyć interfejsu getBoundingClientRect().