WorryFree Computers   »   [go: up one dir, main page]

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, macOS, and Windows. View a complete list of the features in Chrome 70 on ChromeStatus.com. Chrome 70 is beta as of September 13, 2018.

Shape Detection Origin Trial

The Shape Detection API makes a device's shape detection capabilities available on the web, letting you identify faces, barcodes, and text in images. It does this without the use of a performance-killing library. As Chrome 70, this API is available for experimentation through a Chrome origin trial.

The Shape Detection API consists of three APIs: A Face Detection API, a Barcode Detection API and a Text Detection API. Given an image bitmap or a blob, the Face Detection API returns the location of faces and the locations of eyes, noses, and mouths within those faces. To give you rudimentary control of performance, you can limit the number of returned faces and prioritize speed over performance. The Barcode Detection API decodes barcodes and QR codes into strings. (There is a QR code demo at https://qrsnapper.com/) The value can be anything from a single set of digits to multi-line text. The Text Detection API reads Latin-1 text (as defined in iso8859-1) in images. All of these APIs only expose what's supported in the underlying device.

A short example will give you a taste of these APIs, all of which work in a similar fashion. The code below finds all barcodes or QR codes in a given image and prints their values to the console.


const image = document.getElementById('someImage');
try {
  const barcodeDetector = new BarcodeDetector();
  const barcodes = await barcodeDetector.detect(image);
  barcodes.forEach(barcode => console.log(barcodes.rawValue));
} catch (exception) {
  console.error('Boo! Barcode detection failed:', exception);
}

Web Authentication

Chrome 70 has two updates to the Web Authentication API related to the PublicKeyCredential type.

The Credential Management API, enabled in Chrome 51, defined a framework for handling credentials that included semantics for creating, getting, and storing them. It did this through two credential types: PasswordCredential and FederatedCredential. The Web Authentication API adds a third credential type, PublicKeyCredential, which allows web applications to create and use strong, cryptographically attested, and application-scoped credentials to strongly authenticate users. The PublicKeyCredential type was enabled by default on desktop in Chrome 67. In Chrome 70 it is also enabled by default on Android.

Also enabled by default are macOS's TouchID and Android's fingerprint sensor via Web Authentication. These allow developers to access biometric authenticators through the Credential Management API's PublicKeyCredential type.

A Web Authentication verification screen

Other Features in this Release

Displaying a dialog causes pages to lose fullscreen

Dialog boxes, specifically authentication prompts, payments, and file pickers require context for users to make decisions. Fullscreen, by definition is immersive, and removes the context that a user needs to make a decision. Chrome now exits full screen whenever a page shows a dialog box.

HTML

Add referrerpolicy support to <script> elements

Many resource-fetching elements have support for the referrerpolicy attribute, which lets developers provide a keyword to influence the value of the Referer HTTP header that accompanies a request. The <link> element already has support for this, so it is technically possible to preload a script with a developer-set referrer policy. Starting in this version of Chrome, the <script> element supports the referrerpolicy as well.

The <rp> element defaults to display:none

The default style of the <rp> element is changed to display:none instead of display:inline even if it is not inside the <ruby> element as defined in the HTML specification. This behavior is implemented in the user agent stylesheet, but the web author can override it.

Intervention Reports

An intervention is when a user agent does not honor an application request for security, performance, or annoyance reasons. With this change, Chrome can be configured to send intervention and deprecation messages to your servers using the Report-To HTTP Response header field and surface them in the ReportingObserver interface. This is the first of several proposed uses for the Report-To header. Follow these links to learn more about the header and the interface.

Media

Support codec and container switching with MSE using SourceBuffer.changeType()

This change adds the SourceBuffer.changeType() method to improve cross-codec or cross-bytestream transitions during playback with Media Source Extensions.

Support Opus in mp4 with Media Source Extensions

Opus is an audio codec already supported by the HTML5 src attribute on <url> elements. It is now supported by Media Source Extensions.

'name' attribute for dedicated workers

Dedicated workers now have a name attribute, which is specified by an optional argument on the worker's constructor. This lets you distinguish dedicated workers by name when you have multiple workers with the same URL. Developers can print name in the DevTools console which will make it easier to debug workers. When the name parameter is omitted, an empty string is used as the default value. For more information, see the discussion on GitHub.

ontouch* APIs default to disabled on desktop

To avoid confusion on touch feature detection, ontouch* members on window, document, and element are disabled by default on desktop (Mac, Windows, Linux, ChromeOS). Note that this is not disabling touches, and usage such as addEventListener("touchstart", ...) is not affected.

Options dictionary for postMessage methods

An optional PostMessageOptions object has been added as an argument to postMessage() for 6 of the 7 interfaces where it's supported, specifically, DedicatedWorkerGlobalScope, MessagePort, ServiceWorker, ServiceWorker.Client, Window, and Worker. This gives the function a similar interface on its definitions and allows it to be extended in the future. Because broadcastChannel.postMessage() doesn't take additional arguments (such as transfer) it is not being changed.

Rename Atomics.wake() to Atomics.notify()

The Atomics.wake() method is being renamed Atomics.notify(). This is a low-level function to wake a Worker that has been suspended via Atomics.wait(). This conforms to a specification change made to alleviate confusion created by the similarity of the names wait and wake.

RTCPeerConnection.getConfiguration()

This  getConfiguration() was implemented according to the WebRTC 1.0. Specifically it returns the last configuration applied via setConfiguration(), or if setConfiguration() hasn't been called, the configuration the RTCPeerConnection was constructed with.

Symbol.prototype.description

A description property is being added to Symbol.prototype to provide a more ergonomic way of accessing the description of a Symbol. Previously, the description could only be accessed indirectly through Symbol.protoype.toString().

TLS 1.3

TLS 1.3 is an overhaul of the TLS protocol with a simpler, less error-prone design that improves both efficiency and security. The new design reduces the number of round-trips required to establish a connection and removes legacy insecure options, making it easier to securely configure a server. It additionally encrypts more of the handshake and makes the resumption mode more resilient to key compromise.

Update behavior of CSS Grid Layout percentage row tracks and gutters

Percentage row tracks and gutters in grid containers now have indefinite heights. Previously, these were behaving similarly to percentage heights in regular blocks, but the CSS Working Group has resolved to make them behave the same as for columns, making them symmetric. Percentages are now ignored when computing intrinsic height and resolved afterwards against that height. That way both column and row axes will have symmetric behavior to resolve percentages tracks and gutters.

Web Bluetooth available on Windows 10

Web Bluetooth allows websites to communicate over GATT with nearby user-selected Bluetooth devices in a secure and privacy-preserving way. In Chrome 56, this shipped on Android, ChromeOS, and macOS. In Chrome 70 it is shipping on Windows 10. For earlier versions of Windows and Linux, it is still behind a flag (chrome://flags/#enable-experimental-web-platform-features).

WebUSB on Dedicated Workers

WebUSB is enabled inside dedicated workers. This allows developers to perform heavy I/O and processing of data from a USB device on a separate thread to reduce the performance impact on the main thread.

Deprecations and Interoperability Improvements

Chrome sometimes deprecates, removes, or changes features to increase interoperability with other browsers. This version of Chrome includes the following such changes.

Remove AppCache from insecure contexts.

AppCache is now removed from insecure contexts. AppCache is a powerful feature that allows offline and persistent access to an origin, which is a powerful privilege escalation for cross-site scripting. This removes that attack vector by only allowing it only over HTTPS. Developers looking for an alternative to AppCache are encouraged to use service workers. An experimental library is available to ease that transition.

Remove anonymous getter for HTMLFrameSetElement

The anonymous getter for HTMLFrameSetElement is non-standard and therefore removed.

Deprecate and remove Gamepads.item()

The legacy item() accessor is removed from the Gamepads array. This change improves compatibility with Firefox which is so far the only browser to implement GamepadList.

Deprecate Custom Elements v0

Custom Elements are a web components technology that lets you create new HTML tags, beef up existing tags, or extend components authored by other developers. Custom Elements v1 have been implemented in Chrome since version 54, which shipped in October 2016. Custom Elements v0 is now deprecated with removal expected in Chrome 73, around March 2019.

Deprecate HTML Imports

HTML Imports, which allow HTML to be imported from one document to another, are now deprecated. Removal is expected in Chrome 73, around March 2019. Sites depending on HTML imports already require a polyfill on non-Chromium browsers. When HTML imports is removed, sites that have the polyfill should continue to work on Chrome.

Deprecate Shadow DOM v0

Shadow DOM is a web components technology that uses scoped subtrees inside elements. Shadow DOM v1 has been implemented in Chrome since version 53, which shipped in August of 2016. Shadow DOM v0 is now deprecated with removal expected in Chrome 73, around March 2019. Sites depending on HTML imports already require a polyfill on non-Chromium browsers. When Shadow DOM v0 is removed, sites that have the polyfill should continue to work on Chrome.

Deprecate SpeechSynthesis.speak() without user activation

The speechSynthesis.speak() function now throws an error if the document has not received a user activation. This API is being abused by sites since it is one of the only remaining APIs which does not adhere to autoplay policies in Chrome.


Speed has been one of Chrome’s four core principles, since it was first launched ten years ago. We’ve always wanted to enable web developers to provide users with fast, engaging web experiences. On Chrome’s 10th birthday, we thought it would be fun to look at what we’ve done to improve speed over the years and what we’re doing next.



Many components in the browser contribute to speed

V8 is Chrome’s JavaScript and WebAssembly engine. With web pages using an increasing amount of JavaScript, a fast engine to handle it is an important cornerstone. Over the years, we worked on a new JavaScript execution pipeline for V8, launching Ignition (a new interpreter) and TurboFan (an optimizing compiler). These allowed us to improve performance on the Speedometer benchmark by 5-10%. Script streaming enabled us to parse JavaScript on a background thread as soon as it began downloading, improving page loads by up to 10%. We then added background compilation reducing main-thread compile time by up to 20%.

Our work on project Orinoco enabled concurrent garbage collection, freeing up the main thread and reducing jank. Over time, we also shifted to focusing on real-world JavaScript performance, helping us double the performance of the React.js runtime and improve performance for libraries like Vue.js, Preact, and Angular up to 40%. Parallel, concurrent, and incremental garbage collection reduced garbage collection induced jank by 100× since the initial V8 commit. We also implemented WebAssembly, enabling developers to run non-JavaScript code on the web with predictable performance, and launched the Liftoff baseline compiler to ensure fast startup times of WASM apps. These new components are just the latest in a 10-year effort that has improved V8's performance release-to-release for an improvement of 20x over the years.

V8 Bench scores for a range of Chrome releases over the years. V8 Bench is the predecessor to the old Octane benchmark. We've used it for this chart because unlike Octane, it can run in all Chrome versions, including the initial Chrome Beta.

Chrome has also played a key role in helping evolve network protocols and transport layers through SPDY, HTTP/2 and QUIC. SPDY aimed to address limitations of HTTP/1.1 and became the foundation of HTTP/2 protocol, which is now supported by all modern browsers. In parallel, the team has been actively iterating on QUIC, which aims to further improve latency and user experience and now has an active IETF effort behind it. QUIC’s benefits are noticeable for video services like YouTube. Users reported 30% fewer rebuffers when watching videos over QUIC.



Next up is Chrome's rendering pipeline. This is responsible for ensuring webpages are responsive to users and display at 60 frames per second (fps). To display content at 60fps, Chrome has 16ms to render each frame. This includes JavaScript execution, style, layout, paint and pushing pixels to the user's screen. Of this 16ms, the less Chrome uses, the more web developers have to delight their users. Improvements to our rendering pipeline have included optimizing how we identify which elements in a page need to be redrawn and better tracking visually non-overlapping sets. This reduced the time to paint new frames to the screen by up to 35%.

In 2015, a user-centric performance model called RAIL was introduced by the Chrome team. We recently updated it.


What about memory consumption? Between Chrome 63 and 66, a ~20-30% improvement in renderer process memory usage was observed. We hope to continue exploring ways to build on this now that site-isolation has landed. Ignition and TurboFan reduced V8's overall memory footprint, slimming it down by 5-10% on all devices and platforms supported by V8. Some sleuthing this year also discovered memory leaks impacting 7% of sites on the web, which we’ve now fully fixed. Many components contribute to Chrome’s speed including the DOM, CSS and storage systems like IndexedDB. To learn more about our improvements to performance, continue keeping an eye on the Chromium Blog.



Give web developers more power to measure and optimize their web pages


Understanding where to start with improving your site can be a tedious process. To help, we explored several tools for understanding the lab signals and real-world experience felt by your users. Over the years, the Chrome DevTools Performance panel became a powerful way to visualize the play-by-play breakdown of how web pages were displayed in a lab setting. To continue lowering the friction for finding performance opportunities sites had, we then worked on Lighthouse - a tool for analyzing the quality of your website, giving you clear measurements of your site’s performance and specific guidance for improving your users’ experience. Lighthouse can be accessed directly from inside the DevTools Audits panel, run from the command-line, or integrated with other development products like WebPageTest.
Lighthouse running in the Chrome DevTools Audits panel



To complement the lab data provided by Lighthouse, we released the Chrome User Experience Report to help developers get access to field metrics for the experience their users feel in the real-world, such as First Contentful Paint and First Input Delay. Now, developers can build out their own custom site performance reports and track progress over millions of origins using the CrUX Dashboard.


We also introduced a number of Web Platform capabilities to help developers optimize the loading of their sites. We shipped Resource Hints and <link rel=preload> to allow developers to inform the browser what resources are critical to load early on. Chrome was one of the first browsers to implement support for byte-saving approaches like Brotli for compression, WOFF2 for smaller web fonts and WebP support for images.
We’ve been excited to see an increasing number of browsers support these features over time. Chrome implemented Service Workers, enabling offline caching & network resilience for repeat visits to pages. We’re delighted to see broad modern browser support for the feature.

In fact, Google Search now uses Service Worker and navigation preload for opportunistic caching on repeat searches. This led to a 2x improvement in page load times for repeat visits.
As we look to the future, we are also excited about the potential that emerging standards like native lazy-loading for images & iframes, and image formats like AV1 have to help deliver content to users efficiently.

Enjoy more of the web on your data-plan with Chrome


Over the last 10 years, the size of web pages has been ever-increasing, but for many users coming online for the first time, data can be prohibitively expensive or painfully slow. To help, Chrome released data-conscious features over the years like Chrome’s Data Saver. Data Saver intelligently optimizes pages, saving up to 92% on data consumption.

Going ahead, we are exploring new ways to help you save data. For users on the slowest connections, we've been working on Chrome for Android, allowing for smarter page optimizations to show essential content earlier. These page transformations load far faster than the full page, and we're continuing to improve our fidelity, coverage, and performance.

We've also been experimenting with putting guardrails in place for users who are data- or network- constrained. For example, we're exploring bringing native lazy-loading to Chrome, as well as providing users the option to stop additional requests from a page when it uses a lot of data.


We’re just getting started...


Together, these changes help developers and businesses deliver useful content to their users sooner. We know there’s still work to be done. Here’s to offering improvements to page load performance over another 10 years!


Posted by Addy Osmani, JavaScript Janitor

NOTE: This article was inspired by a conversation with Darin Fisher, VP for Google Chrome, for our YouTube series “Designer vs. Developer”.

To release a browser when there were already established ones in the market was a bold move—especially when some of the major browsers were clocking over a million downloads within just hours of their release.
The community speculated about a Google browser as early as 2004, but the team actually started working on the project in 2006. With the rise in rich web applications such as Gmail, YouTube, and Google Maps, the demand for more powerful browsers became apparent. These new web apps were processor-intensive and the browsers weren’t designed to handle that level of complexity.


“In your typical browser of that day, if you were to leave Gmail running overnight, you would come back the next day and your browser would feel pretty sluggish.”
– Darin Fisher, VP Chrome



Browsers of that time mimicked what early search engines had done, diluting the focus on the core user experience. Search engines were mostly portal sites with a sea of links and a tiny input field. Google Search stripped away the clutter, offering the user a single input field, and focused on a single task.



Web browsers had created a similar problem with excessive toolbars. Whenever users installed a new app, they were offered an extra toolbar. Eventually, the browser UI dominated the user's screen real estate and left very little space for content. Chrome wanted to do what Google did with search: focus on content. The team wanted to get out of the user’s way and include features that weren’t possible before, such as draggable tabs. Even the extension system was built to ensure that the screen space for content wasn’t compromised and that the surrounding UI was minimized as much as possible.



The mantra for Chrome was the four S’s: simplicity, speed, security, and stability.



Simplicity represented the streamlined UI design and experience. Speed was about how quickly the browser responded when a user performed an action. Speed wasn’t just about load time, either. Before Chrome, browsers would often hang or fail to respond when a user tried to close a tab, had too many tabs open, or was doing something complicated on a page. Chrome worked on a multiprocessor architecture, so if the user clicked to close a tab, it would simply close.



Security was about making users feel safe on the web, protecting them from any nasties on the internet such as viruses or fake sites, and giving them control over what was happening. This tied into the final S -- Stability of the browser, ensuring that it wouldn’t randomly crash. The team put a lot of effort in making sure it supported the many quirks on the web and rendered pages in a way that web developers intended.



I asked Darin about the things he is proud of and the decisions he regretted. He mentioned the liberation of starting with the Windows version, which meant his teams could focus on building a great browser without thinking about any cross-platform issues. While it maintained the free-spirit of development for the team, to their peril, they had to recreate everything from scratch when building for mobile, MacOS and Linux - a painful but critical learning of ‘thinking long-term’ for him and the team.



The other challenge I asked him about was the dreaded “best viewed in browser X” banner message that was common in the early 2000s, indicating that site content might not show properly on some browsers (including Chrome). Today, Chrome is working with other browsers vendors, the W3C committee, and especially developers, to make sure we’re solving the right problems for the community, such as the cross-collaboration work we did when implementing CSS Grid.



What do the next ten years hold? As new computers, mobile devices, and users come online, the most likely effect will be that design patterns and trends from Asia and Africa become the standard way of experiencing digital design. Web makers in India have pioneered offline experiences, and app designers in Nigeria are developing new ways of delivering Ecommerce experiences to users on 2G networks.



So, here’s to the next ten years. Happy birthday, Chrome!




Chrome is turning 10! Thank you for making the web development community so open, collaborative, and supportive. DevTools draws inspiration from countless other projects. Here’s a look back at how DevTools came about, and how it’s changed over the years.



In the beginning, there was Firebug

Imagine for a moment that browsers didn't ship with developer tools. How would you debug JavaScript? You'd basically have 3 options:
  • Sprinkle window.alert() calls throughout your code.
  • Comment out sections of code.
  • Stare at the code for a long time until the JavaScript gods bless you with a solution.
What about layout issues? Network errors? Again, all you could really do is conduct painstaking experiments in your code. This was the reality of web development up until 2006. Then a little tool called Firebug came along and changed everything.


A screenshot of Firebug's Net panel, taken from
Saying Goodbye to Firebug (source and license)

Firebug was a Firefox extension that let you debug, edit, and monitor pages in real-time. As a web developer suddenly you went from having no visibility into your pages to having what are essentially the core features of modern developer tools. The ability to understand exactly why Firefox was behaving as it was unleashed a flood of creativity on the web. Without Firebug, the Web 2.0 era wouldn't have been possible.




WebKit Web Inspector


Around the same time as Firebug’s launch, a few Google engineers started working on a project which would eventually lead to Chrome. From the start, Chrome was a mashup of different code libraries. For rendering the Chrome engineers opted for WebKit, which is the open-source project that still powers Safari to this day. An added bonus of using WebKit was that it came with a handy tool called the Web Inspector.


A screenshot of the Web Inspector, taken from Web Inspector Redesign (source and license)

Like the Net panel of Firebug, the original Web Inspector probably looks familiar. Much of its functionality lives on to this day as the Elements panel in Chrome DevTools. Web Inspector launched a few days after Firebug, and Safari was the first browser to bundle developer tooling directly into the browser.




The "Inspect Element" era


Chrome brought many innovative ideas to the browser ecosystem, such as the omnibox that combined search and the address bar, and a multi-process architecture that prevented one hanging tab from crashing the entire browser. But the innovation we like the most was providing developer tools in every build to every user, exposed with the click of a mouse.

"Inspect Element" in 2010



Before Chrome, developer tooling was an opt-in experience. You either had to install an extension, like Firebug, or enable some flags, as is still the case in Safari today. Chrome was the first browser to make developer tooling accessible from every browser instance. We'd like to claim that we had a grand vision for creating a developer-friendly browser from the start, but the reality is that Chrome had a lot of compatibility issues in its early days (which makes sense, since no one was building for it) and we needed to give web developers an easy way to fix these issues. Web developers told us that it was a useful feature, and we kept it.



The mobile era


For the first few years of the DevTools project, we essentially added chapters to the stories that Firebug and Web Inspector started. The next big shift in how we approached DevTools happened when it became clear that smartphones were here to stay.
Our first mission in this brave new world was to enable developers to debug real mobile devices from their development machines, which we call remote debugging. DevTools was actually well-positioned to handle remote debugging, thanks to another consequence of Chrome’s multi-process architecture. Early on in the DevTools project we realized that the only way a debugger could reliably access a multi-process browser was through a client-server protocol, with the browser being the server, and the debugger being the client. When mobile Chrome came around, the protocol was already baked into it, so we just had to make the DevTools running on your development machine communicate with the Chrome running on your mobile device over the protocol. This protocol still forms the backbone of DevTools today, and is now known as the Chrome DevTools Protocol.

Remote Debugging

Remote debugging was a step in the right direction, and to this day is still the primary tool for making sure that your sites behave reasonably on real mobile devices. Over time, however, we realized that remote debugging could be a bit tedious. When you're in the early phases of building out a site or feature, you usually just need a first-order approximation of the mobile experience. This prompted us to create a set of mobile simulation features, such as:

  • Precisely emulating the mobile viewport, simulating touch-based input and device orientation.
  • Throttling the network connection to simulate 3G and CPU to simulate less-powerful mobile hardware.
  • Spoofing user agent, geolocation, accelerometer data and more.

We collectively refer to these features as Device Mode.






An early prototype of Device Mode


Device Mode in 2018


The performance era


While the mobile era unfolded, big apps like Gmail were pushing the limits of the web's capabilities. Gmail-scale bugs called for Gmail-scale tools. One of our first major contributions to the tooling ecosystem was to show a play-by-play breakdown of exactly everything that Chrome had to do in order to display a page.


The original Timeline panel, as announced in Do More with Chrome Developer Tools


The Performance panel in 2018


These tools were a step in the right direction, but in order to spot optimization opportunities you needed to learn the nitty-gritty details about how browsers work and sift through a lot of data. Lately we've been building on this foundation to provide more
guided performance insights. The new Lighthouse engine powers the Audits panel, and is also available as a Node module for integration with CI systems.


Performance suggestions in the Audits panel


The Node.js era


Up until 2014 or so, we mainly thought of DevTools as a tool for building great experiences on Chrome. The rise of Node prompted us to rethink our role in the web ecosystem.
For the first few years of Node's existence, Node developers were in a situation similar to that of web developers before Firebug, or Gmail developers before the Timeline panel: the scale of Node apps outpaced the scale of Node tools. Given that Node runs on Chrome's JavaScript engine, V8, DevTools was a natural candidate to fill the gap. Support for debugging Node with DevTools landed in 2016 and includes the usual DevTools features, such as breakpoints, code stepping, blackboxing, source maps for transpiled code, and so on.
Node Connection Manager



The DevTools protocol ecosystem


The name Chrome DevTools Protocol (CDP) suggests an API that only DevTools can use. The reality is more general than that: it’s the API that enables programmatic access to Chrome. Over the last few years, we've seen a few third-party libraries and applications join the protocol ecosystem:
  • chrome-remote-interface provides low level JavaScript access to the protocol
  • Puppeteer brings it to the next level of abstraction and enables automation of the evergreen headless Chrome browser with modern JavaScript API
  • Lighthouse automates the process of finding ways to improve the performance and quality of pages

We're excited to see thousands of projects depend on these packages to enable rich interaction with Chrome. If you’re in the tooling or automation business, it’s worth checking out the protocol to see if it opens up any opportunities in your domain. For example, the VS Code and WebStorm teams both use it to enable JavaScript debugging within their respective IDEs.

What's next?


Our core mission is to build tools that help you create great experiences on the web. We very much rely on your feedback to help us determine what products or features to build.


Thank you for creating such a vibrant community. We look forward to another 10 years of building the web with you.

Posted by the Chrome DevTools team