W niemal każdej wersji Chrome obserwujemy znaczną liczbę aktualizacji i ulepszeń produktu, a także jego wydajności, a także możliwości platformy internetowej.
W Chrome 49 (beta) 2 lutego 2016 r. szacowana data stabilna: marzec 2016 r.). W Chrome wprowadzono wiele zmian.
Używanie prefiksu „css” w metodzie getComputedStyle(e).cssX zostało wycofane
TL;DR: użycie prefiksu „css” w języku getComputedStyle(e) zostało wycofane, ponieważ nie wchodziło on w formalną spec.
getComputedStyle to świetna funkcja. Zwrócone zostaną wszystkie wartości CSS stylów elementu DOM obliczone przez mechanizm renderowania. Możesz np.uruchomić getComputedStyle(_someElement_).height, który może zwrócić wartość 224,1 piksela, ponieważ taka jest wysokość aktualnie wyświetlanego elementu.
Interfejs API wydaje się dość przydatny. Co zmieniamy?
Zanim mechanizm renderujący Chrome zmienił się na Blink, obsługiwał on technologię WebKit, dzięki której na początku usługi można było dodać prefiks „css”. Na przykład getComputedStyle(e).cssHeight zamiast getComputedStyle(e).height.
Oba rodzaje danych zwróciłyby te same dane, które były zmapowane na te same wartości bazowe, ale takie użycie prefiksu „css” było niestandardowe i zostało wycofane i usunięte.
Uwaga: cssFloat to usługa standardowa, której wycofanie nie ma wpływu na jej wycofanie.
Jeśli otworzysz daną usługę w ten sposób w Chrome 49, zwróci ona wartość undefined i będzie trzeba naprawić kod.
Używanie funkcji initTouchEvent zostało wycofane
TL;DR:
wycofaliśmy wersję initTouchEvent i zastąpiliśmy ją TouchEvent
constructor, aby poprawić zgodność ze specyfikacjami. Zostanie ona całkowicie usunięta w Chrome 54.
Intencja do usunięcia Narzędzie do śledzenia stanu Chrome Problem z błędem CRBug
Od dawna możesz tworzyć syntetyczne zdarzenia dotyku w Chrome za pomocą interfejsu initTouchEvent API. Często służą one do symulowania zdarzeń dotknięcia na potrzeby testowania lub automatyzacji niektórych elementów interfejsu witryny. W Chrome 49 wycofaliśmy ten interfejs API i będziemy wyświetlać to ostrzeżenie z myślą o całkowitym usunięciu go w Chrome 53.
Istnieje kilka powodów, dla których ta zmiana jest dobra.
Nie ma ich też w specyfikacji zdarzeń dotknięcia. Implementacja Chrome initTouchEvent w ogóle nie była zgodna z interfejsem API initTouchEvent w Safari i różna od Firefoksa na Androidzie. I wreszcie konstruktor TouchEvent jest o wiele prostszy w użyciu.
Postanowiliśmy, że postaramy się postępować zgodnie ze specyfikacją, a nie utrzymać interfejs API, który nie jest specyficzny ani zgodny z jedyną inną implementacją.
W związku z tym najpierw wycofujemy i usuwamy funkcję initTouchEvent. Wymagamy od programistów korzystania z konstruktora TouchEvent.
Jest używany w internecie, ale wiemy, że jest on używany przez stosunkowo niewiele witryn, dlatego nie usuwamy go tak szybko, jak jest to możliwe. Wydaje nam się, że witryna nie działa poprawnie, ponieważ witryny nie obsługują wersji podpisu Chrome.
Ponieważ implementacje interfejsu API initTouchEvent na iOS i Androidzie/Chrome różnią się tak bardzo,
często umieszczasz kod podobny do (często zapominasz o przeglądarce Firefox).
var event = document.createEvent('TouchEvent');
if(ua === 'Android') {
event.initTouchEvent(touchItem, touchItem, touchItem, "touchstart", window,
300, 300, 200, 200, false, false, false, false);
} else {
event.initTouchEvent("touchstart", false, false, window, 0, 300, 300, 200,
200, false, false, false, false, touches, targetTouches, changedTouches, 0, 0);
}
document.body.dispatchEvent(touchEvent);
Po pierwsze, nie jest to możliwe, bo szukanie ciągu „Android” w interfejsie User-Agent i Chrome na Androidzie zostanie dopasowane i wycofane. Nie można jej jednak jeszcze usunąć, ponieważ przez jakiś czas na Androidzie będą pojawiać się inne przeglądarki oparte na WebKit i starszych wersjach Blink, które wymagają obsługi starszego interfejsu API.
Aby zapewnić prawidłową obsługę polecenia TouchEvents w internecie, zmień kod tak, aby obsługiwał Firefox, IE Edge i Chrome. W tym celu sprawdź, czy obiekt window ma dodatnią „długość” (wskazuje na to konstruktor, który przyjmuje argument) oraz czy istnieje obiekt TouchEvent.
if('TouchEvent' in window && TouchEvent.length > 0) {
var touch = new Touch({
identifier: 42,
target: document.body,
clientX: 200,
clientY: 200,
screenX: 300,
screenY: 300,
pageX: 200,
pageY: 200,
radiusX: 5,
radiusY: 5
});
event = new TouchEvent("touchstart", {
cancelable: true,
bubbles: true,
touches: [touch],
targetTouches: [touch],
changedTouches: [touch]
});
}
else {
event = document.createEvent('TouchEvent');
if(ua === 'Android') {
event.initTouchEvent(touchItem, touchItem, touchItem, "touchstart", window,
300, 300, 200, 200, false, false, false, false);
} else {
event.initTouchEvent("touchstart", false, false, window, 0, 300, 300, 200,
200, false, false, false, false, touches, targetTouches,
changedTouches, 0, 0);
}
}
document.body.dispatchEvent(touchEvent);
W metodach RTCPeerConnection wymagane są moduły obsługi błędów i sukcesów
TL;DR: metody RTCPeerConnection createOffer() i createAnswer() w WebRTC obecnie wymagają modułu obsługi błędów oraz modułu obsługi powodzenia. Wcześniej można było wywoływać te metody tylko z użyciem modułu obsługi sukcesu. To wykorzystanie jest przestarzałe.
W Chrome 49 dodaliśmy ostrzeżenie w przypadku wywoływania setLocalDescription() lub setRemoteDescription() bez podawania modułu obsługi błędów. W Chrome 50 planujemy, że argument modułu obsługi błędów
będzie obowiązkowy w przypadku tych metod.
Jest to część sposobu na wprowadzanie obietnic do tych metod, zgodnie ze specyfikacją WebRTC.
Oto przykład z prezentacji 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);
}
Zarówno parametr setLocalDescription(), jak i setRemoteDescription() zawsze miały parametr modułu obsługi błędów, więc jego podanie jest bezpieczne.
Ogólnie w przypadku produkcyjnych aplikacji WebRTC zalecamy korzystanie z adapter.js – podkładki zarządzanej przez projekt WebRTC – do odizolowania aplikacji przed zmianami specyfikacji i różnicami prefiksów.
Element Document.defaultCharset został wycofany
TL;DR: narzędzie Document.defaultCharset zostało wycofane, aby poprawić zgodność ze specyfikacjami.
Intencja do usunięcia Narzędzie do śledzenia stanu Chrome Problem z błędem CRBug
Document.defaultCharset to właściwość tylko do odczytu, która zwraca domyślne kodowanie znaków systemu użytkownika na podstawie jego ustawień regionalnych. Utrzymywanie tej wartości nie jest przydatne ze względu na to, jak przeglądarki używają informacji o kodowaniu znaków w odpowiedzi HTTP lub w metatagu umieszczonym na stronie.
Za pomocą parametru document.characterSet otrzymasz pierwszą wartość określoną w nagłówku HTTP. Jeśli go nie ma, otrzymasz wartość określoną w atrybucie charset elementu <meta> (np. <meta charset="utf-8">).
Jeśli żadna z tych wartości nie jest dostępna, wartością document.characterSet będzie ustawienie systemowe użytkownika.
Gekon nie obsługuje tej właściwości i nie jest w jasny sposób określony, dlatego zostanie wycofana z funkcji Blink w Chrome 49 (beta) w styczniu 2016 r. Dopóki nie usuniesz usługi w Chrome 50, w konsoli będzie wyświetlane to ostrzeżenie:
Więcej o powodach niepodania tej specyfikacji znajdziesz na github: https://github.com/whatwg/dom/issues/58.
Usunięto metodę getStorageUpdates()
TL;DR: plik Navigator.getStorageUpdates() został usunięty, ponieważ nie ma go już w specyfikacji nawigatora.
Intencja do usunięcia Narzędzie do śledzenia stanu Chrome Problem z błędem CRBug
Jeśli będzie to miało miejsce, przełknę kapelusz. getStorageUpdates() rzadko (jeśli w ogóle) była używana w internecie.
Aby zacytować (bardzo starszą wersję) specyfikacji HTML5:
Brzmi nieźle, prawda? Specyfikacja zawiera nawet słowo „kiedy” (co jest jedynym wystąpieniem w specyfikacji). Na poziomie specyfikacji dostępny był moduł StorageMutex kontrolujący dostęp do blokowania pamięci, np. localStorage i plików cookie, a ten interfejs API pomógłby usunąć muteks, aby inne skrypty nie były blokowane przez ten element StorageMutex. Nigdy nie wdrożono go i nie jest on obsługiwany w IE ani Gecko, a wdrożenie WebKit (a tym samym również Blink) nie było możliwe.
Już od jakiegoś czasu jest usuwana ze specyfikacji i całkowicie usunięta z Blink (przez dłuższy czas nic się nie dzieje i nie daje żadnych wyników, nawet po powrocie).
W bardzo rzadkich przypadkach, gdy kod wywołał funkcję navigator.getStorageUpdates(), przed jej wywołaniem trzeba będzie sprawdzić jej obecność.
Interfejs Object.observe() został wycofany
TL;DR: interfejs Object.observe() został wycofany, ponieważ nie jest już na ścieżce standaryzacji i zostanie usunięty w kolejnej wersji.
Intencja do usunięcia Narzędzie do śledzenia stanu Chrome Problem z błędem CRBug
W listopadzie 2015 r. ogłosiliśmy, że organizacja Object.Observe zostanie wycofana z uczestnictwa w programie TC39. Została wycofana z Chrome 49 i jeśli spróbujesz jej użyć, zobaczysz w konsoli to ostrzeżenie:
Wielu deweloperów lubi ten interfejs API. Jeśli eksperymentujesz z nim i szukasz ścieżki przejścia, rozważ użycie kodu polyfill takiego jak MaxArt2501/object-observe lub biblioteki opakowań, takiej jak polymer/observe-js.