[go: up one dir, main page]

The app launcher makes Chrome apps easy to open outside the browser, but we’ve found that users on Windows, Mac, and Linux prefer to launch their apps from within Chrome. With Chrome’s continued emphasis on simplicity and streamlining browser features, the launcher will be removed from those platforms. It will remain unchanged on Chrome OS.


The removal process will take place over the next several months. Beginning in a few weeks, Chrome will no longer enable the launcher when users first install a Chrome app. Anyone who currently has the launcher will receive a notice informing them that the launcher will be going away. In July, existing instances of the launcher will be removed. 


Chrome apps can still be accessed by clicking the apps shortcut in the bookmarks bar or typing chrome://apps in the omnibox. Learn more about opening Chrome apps by visiting the help center.


Posted by Marc Pawliger, Engineering Director

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.


Push notification improvements
Push notifications allow a site to trigger system-level notifications in the same way that native applications do. The initial version of push notifications relied on service workers to proactively fetch the information for a notification from the server. This led to problems when there were multiple messages in flight or when the device was on a flaky network connection. The latest version of Chrome allows sites to include notification data payloads with their push messages to eliminate the final server check. To protect user privacy, push notification payloads must be encrypted. Push notification payloads are part of the Push API spec and already supported in Firefox.

 In addition to payloads, sites can now detect when a notification is closed by the user, enabling better analytics and allowing cross-device notification dismissal. Sites can also control the look of notifications more finely, setting custom timestamps and icons for notification actions. When updating a notification, sites can specify whether the device should alert the user with sound or vibration, or remain silent.


In Chrome 50, notification actions support custom icons.

Declarative preload
Sometimes there are resources needed to fully display a page that Chrome doesn’t know about until other resources are loaded. For example, a large JavaScript file may require a particular stylesheet, but Chrome doesn’t know to load the CSS until the JavaScript has run. Chrome now supports the <link rel='preload'> attribute, allowing developers to specify resources that should be downloaded preemptively and reducing the time to get meaningful content in front of users.

Chrome 50 (left) loading a page with preload vs. Chrome 49 (right) loading the page without.
Other features in this release

Minor changes

  • Chrome now supports the X25519 curve for TLS, allowing faster, simpler encryption.
  • -webkit-background-composite has been removed since it was nonstandard and had low usage.
  • The SVGZoomEvent, which was a no-op in Chrome, has been deprecated to improve spec compliance.
  • The RTCPeerConnection methods createOffer() and createAnswer() have been deprecated to enable promise-based implementations.
  • <link rel='subresource'> has been deprecated in favor of <link rel='preload'>, as described above.
  • XMLHTTPRequestProgressEvent has been removed in favor of ProgressEvent to improve spec compliance.
  • The Document.defaultCharset attribute has been removed to improve spec compliance.
  • KeyboardEvent.prototype.keyLocation has been removed in favor of KeyboardEvent.prototype.location, which is supported across more browsers.
  • The SVGElement.offset* methods have been removed from all elements except HTMLElement to improve spec compliance.



Posted by Peter Beverloo and Nicolás Satragno, Notification Knights








Labels:

Last year we announced our intent to end support for the experimental protocol SPDY in favor of the standardized version, HTTP/2. HTTP/2 is the next-generation protocol for transferring information on the web, improving upon HTTP/1.1 with more features leading to better performance. Since then we've seen huge adoption of HTTP/2 from both web servers and browsers, with most now supporting HTTP/2. Over 25% of resources in Chrome are currently served over HTTP/2, compared to less than 5% over SPDY. Based on such strong adoption, starting on May 15th — the anniversary of the HTTP/2 RFC — Chrome will no longer support SPDY. Servers that do not support HTTP/2 by that time will serve Chrome requests over HTTP/1.1, providing the exact same features to users without the enhanced performance of HTTP/2.

At the same time, Chrome will stop supporting the TLS protocol extension NPN, which allows servers to negotiate SPDY and HTTP/2 connections with clients. NPN has been superseded by the TLS extension ALPN, published by the IETF in 2014. ALPN is already used 99% of the time to negotiate HTTP/2 with Chrome, and the remaining servers can gain ALPN support by upgrading their SSL library.

We are looking forward to HTTP/2 continuing to gain adoption, bringing us an even faster web.

Update: To better align with Chrome's release cycle, SPDY and NPN support will be removed with the release of Chrome 51.

Posted by Bence Béky, Network Protocol Engineer and HTTP/2 Enthusiast

The Physical Web helps users discover URLs relevant to their surroundings via Eddystone bluetooth low-energy beacons. Last year, Chrome for iOS took an initial step in supporting the Physical Web, and the community has already begun exploring promising applications. Starting in version 49, Chrome for Android will also surface Physical Web content, making these experiences available to an even larger audience.
As Physical Web-enabled beacons are becoming more widespread, developers are experimenting with the platform in various ways. One Physical Web demo posted by a Mozilla community contributor shows users how to use bluetooth beacons to discover and interact with a drone. Brookwood Middle School uses beacons from BKON to circulate class notes, sports accomplishments, and news updates. Radius Networks, a beacon manufacturer, recently deployed 1,500 beacons to help attendees of CES® (Consumer Electronics Show) navigate showrooms. The Golden State Warriors utilize the Physical Web with the help of Signal360 to provide fans with highlight videos and welcome content at Oracle Arena.
Physical Web bluetooth beacons enabled a scavenger hunt at CES® 2016.
Now, Physical Web developers can reach Chrome for Android users as well, starting with the Beta channel and rolling out more widely soon. When these users walk by a beacon for the first time, they’ll receive a notification allowing them to enable the Physical Web. On future encounters with beacons, users can quickly see a list of nearby URLs by tapping on a non-vibrating notification waiting for them.


pwvending.gif
Physical Web experience on Chrome for Android
Developers can make their web content discoverable on the Physical Web by configuring an Eddystone-supported beacon to broadcast a URL of their choice with the Eddystone-URL frame type. Now that the Physical Web is tightly integrated into Chrome for Android, a single deployment can deliver contextual information to Chrome users across multiple mobile platforms.


As we continue to improve the Physical Web experience, we’re excited to see what types of contextual experiences developers build. We encourage anyone to join the conversation on our mailing list and visit the Physical Web cookbook to learn more about what’s possible.

Posted by Ani Mohan, Physical Web Voyager

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.

CSS custom properties
Modern websites often have CSS files with repeated values, such as a few colors reused throughout the page in a color scheme. Altering this data can be tedious and error-prone, since it’s scattered throughout one or more CSS files. To improve this, Chrome now supports CSS custom properties, allowing developers to define property variables in CSS without using external frameworks. Developers can then use the var() function to reference these custom properties anywhere in the document.

Changing a custom property can update multiple components in a website

CSS custom properties also inherit across shadow roots, so a web component can provide a “style API” that makes it possible to tweak and theme the component without knowing about its internals. The Polymer library uses this platform feature to simplify customizing components.

Background sync with service workers
Previously, sites could lose local changes or become out of sync if a user didn’t stay on the site until updates could be sent over the network. For example, an email client might lose a pending message if the user hit "send" and quickly navigated away. The new Background Sync API improves networking reliability by allowing service workers to schedule a one-off sync of a user’s local changes when the device next connects to the network, even if the site isn’t open.

Improved ECMAScript 2015 support
The ES2015 specification (ES6) is a major update to JavaScript that allows developers to write application logic that is more legible, powerful, and memory efficient. The latest version of Chrome’s V8 engine has 91% JavaScript ES2015 feature support. Developers can now use destructuring and default parameters to avoid boilerplate code when extracting data from arrays and objects or when setting function parameter defaults. Proxy objects and the Reflect API can customize previously hidden object behavior such as property lookup and assignment. The latest version of Chrome also makes block-level constructs such as class and let available outside of strict mode.

Keygen and application/x-x509-user-cert
The <keygen> element is used to generate a key-pair as part of an HTML form. While this can be used to enhance user security, <keygen> and user certificates sent with the MIME type of application/x-x509-user-cert can be exploited to disrupt a user’s secure communication, interfere with the functioning of their devices, or track the user without consent. Going forward, <keygen> will return an empty string by default and user certificates sent with the MIME type of application/x-x509-user-cert will no longer be automatically downloaded and installed.

Other features in this release

Minor changes

Posted by Josh Karlin, Syncing Samurai

Labels: