W niemal każdej wersji Chrome obserwujemy znaczną liczbę aktualizacji i ulepszeń usługi, a także jej 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ąć.
Metoda Document.defaultCharset została usunięta
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, to tylko-do-odczytu właściwość zwracająca 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 go nie podasz, otrzymasz wartość określoną w atrybucie charset elementu <meta> (np. <meta
charset="utf-8">). Jeśli żadna z tych wartości nie będzie dostępna, document.characterSet będzie ustawieniem systemowym użytkownika.
Więcej informacji o przyczynach, dla których nie chcemy tworzyć specyfikacji, znajdziesz w tym wątku na GitHubie.
Atrybut podrzędnego zasobu został usunięty z elementu linku
TL;DR: usuń obsługę wartości subresource atrybutu rel w atrybucie HTMLLinkElement.
Intend to Remove | Chromestatus Tracker | Chromium Bug
Celem atrybutu subresource w elemencie <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 je po prostu pobrać z pamięci podręcznej przeglądarki.
Atrybut subresource miał wiele problemów. Po pierwsze, nigdy nie działało
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 dwukrotnie.
Deweloperzy, którzy chcą zwiększyć wygodę użytkowników dzięki wstępnemu wczytywaniu treści, mają do wyboru kilka opcji. Najbardziej elastyczne jest utworzenie elementu workera usługi, który będzie korzystać z wstępnego wczytywania 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.
Usuń zastępczą wersję TLS
TL;DR: usuń mechanizm wymuszania na serwerach zwracania danych przy użyciu 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.
Zamiar usunięcia | Narzędzie do śledzenia stanu Chrome | Błąd w Chromium
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. Na przykład oba atrybuty pozwalają programistom rozróżnić 2 klawisze 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. Argument modułu obsługi błędów jest wymagany od wersji Chrome 50.
Jest to część działań mających na celu ułatwienie wprowadzenia obietnic dotyczących tych metod zgodnie z wymaganiami specyfikacji WebRTC.
Oto przykład z demonstracji RTCPeerConnection 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 wraz z atrybutami position i totalSize zostanie usunięty.
Zamiar usunięcia | Narzędzie do śledzenia stanu Chrome | Błąd w Chromium
To zdarzenie istniało, aby obsługiwać właściwości zgodności Gecko position i totalSize. 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
TL;DR: zaszyfrowane rozszerzenia multimediów z prefiksami zostały usunięte i zastąpione oparta na specyfikacjami, bez prefiksu.
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.
Zamiar usunięcia | Narzędzie do śledzenia stanu Chrome | Błąd w Chromium
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().