Chromium Blog: Chrome 59 Beta: Headless Chromium, native notifications on macOS, and service worker navigation preload

Chrome 59 Beta: Headless Chromium, native notifications on macOS, and service worker navigation preload

Tuesday, May 2, 2017

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows. Headless Chromium Headless Chromium allows running Chromium in an automated environment without a user interface or peripherals. This enables use cases such as automating unit tests with Selenium and converting a web page into a PDF.

Headless Chromium is powered by all the modern web platform features provided by Chromium and Blink. Support is now available on Mac and Linux, with a Windows implementation coming soon. Native notifications on macOS Chrome has historically included its own notification system for web and extension developers to send notifications to users. In response to macOS introducing its own rich notification system, many users have asked for the two systems to be integrated.

In Chrome 59, when developers send notifications via the Notifications API or chrome.notifications, they will be shown directly by the macOS native notification system. This change improves the user experience, but some low-usage API features are now discouraged since they result in a degraded experience on macOS, as documented in the migration guide.

Chrome notifications before and after integration with the native notification system.
Service worker navigation preload The Service Worker navigation preload API enables the browser to preload navigation requests while a service worker is starting up. These requests are started before executing the fetch event handler in the service worker intercepting the target URL. This gives the worker access to the preload response inside the fetch event handler, allowing the service worker to handle the navigation with minimal delay. Other features in this release

Developers can now use MediaError.message to obtain greater detail about a MediaError produced by <audio> or <video>.

WritableStreams are now available as part of the Streams API for processing streams of data, while providing a standard abstraction for writing streaming data to a sink with built-in backpressure and queuing.

The Streams API has been expanded with the ability to pipe between ReadableStreams and WritableStreams via the pipeTo() and pipeThrough() methods, allowing easier consumption of streaming data.

Developers can now use the getInstalledRelatedApps function to smartly consolidate push notifications between related web and native apps by suggesting when and on which platform to offer them.

The Image Capture API now allows sites to take higher resolution images than before, providing full control over camera settings such as zoom, ISO, and white balance.

To provide enhanced privacy, CSS stylesheets can now specify their own referrer policy via the HTTP header, rather than always inheriting the referrer policy of the document that originally referenced it.

To avoid over-prompting users, Chrome will now temporarily stop an origin from requesting a permission following the third dismissal of that permission request.

Touch events are now aligned to requestAnimationFrame, ensuring that input is processed as part of the document lifecycle and creating a more efficient and adaptive input response.

The new worker-src Content Security Policy directive restricts which URLs may be loaded as a Worker, SharedWorker, or ServiceWorker.

The Presentation Receiver API is now available, enabling a web page to be presented and developers to interact with the presenting web page.

Deprecations and interoperability improvements

The <dialog> element has changed from display: inline to block by default to better align with the spec.

Following removal from the Media Queries spec, support for hover: on-demand and any-hover: on-demand media queries have been removed.

To better align with spec and help avoid race conditions, decodeAudioData now detaches the given ArrayBuffer before decoding, removing all content from the object and making it unable to be reused or examined.

To increase security, Chrome no longers supports requesting notification permission over HTTP.

The -internal-media-controls-cast-button CSS selector has been removed in favor of the Remote Playback API.

The -internal-media-controls-text-track-list* CSS selectors have been removed in favor of custom-built video controls.

The SVGTests.requiredFeatures attribute has been deprecated following its removal from the spec.

initDeviceMotionEvent() and initDeviceOrientationEvent() were removed in favor of DeviceOrientationEvent() and DeviceMotionEvent(), following a spec trend of moving away from initialization functions and toward constructors.

To preserve consistency across browsers, the sample property will now be included in a violation report (and associated SecurityPolicyViolationEvent object) if a report-sample expression is present in the violated directive.

To increase security, Chrome will now block requests for subresources that contain embedded credentials, and instead handle them as network errors.

To increase security, Chrome will now block requests from HTTP/HTTPS documents to ftp: URLs.

To preserve consistency across browsers, injecting JavaScript via AppleScript is longer supported in Chrome for Mac.

The ability to call Notification.requestPermission() from non-main frames has been deprecated to align the requirements for notification permission with requirements for push notifications, and ease friction for developers. 

Support for Shared Dictionary Compression (SDCH) has been disabled until a stable API has been standardized.

Posted by Sami Kyostila, Headless Honcho

Chromium Blog

Chrome 59 Beta: Headless Chromium, native notifications on macOS, and service worker navigation preload

Labels

Archive

Feed