Tumblelog by Soup.io
Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

February 02 2017


Chrome 57 Beta: CSS Grid Layout, Improved Add to Home screen, Media Session API

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

CSS Grid Layout

Sites are increasingly being accessed on screens of all sizes, from large LCD TVs to tiny watch faces. Historically, supporting all of these screen sizes required complex combinations of markup and CSS, making code hard to maintain. To give developers more granular control over how elements grow and shrink to fit the current screen size, CSS Grid Layout is now available .

CSS Grid supports a two-dimensional grid-based layout system, optimized for responsive user interface design. Elements within the grid can be specified to span multiple columns or rows. Elements positioned in a CSS grid can also be named, making layout code easier to understand.
Screenshot 2017-01-25 20.06.19.png
CSS Grid allows developers to arbitrarily place elements on a grid with full control over element flow, sizing behavior and responsiveness.

Improved Add to Home screen

Since early versions of Chrome for Android, users have been able to add sites to their Home screen for fast and convenient access. This feature adds the icons using Android shortcuts , which means that web apps don’t show up throughout Android in the same way as installed native apps.

In this release, when a user adds a Progressive Web App to their Home screen, Chrome will integrate it into Android in a much deeper way . For example, Progressive Web Apps will now appear in the app drawer section of the launcher and in Android Settings, and will be able to receive incoming intents from other apps. Long presses on their notifications will also reveal the normal Android notification management controls rather than the notification management controls for Chrome.

Media Session API

Media consumption is one of the most common uses for the mobile web. In Chrome for Android, developers can customize the lock screen UI and notifications with media content using the new Media Session API . By providing metadata to the browser about the content being played, developers can create rich lock screen messaging that includes information such as title, artist, album name, and artwork. Additionally , the site is now able to respond to user actions taken on the notification itself, such as seeking or skipping.


Other features in this release

  • When a video enters fullscreen on an Android device, Chrome now automatically locks the screen orientation according to the aspect ratio of the video.
  • Sites using continuous setTimeout() will now be throttled when using loops to drive out-of-view frame animations, improving performance for users.
  • The Fetch API Response class now supports the .redirected attribute to help web developers avoid untrustworthy responses and reduce the risk of open redirectors .
  • The new padStart and padEnd formatting tools enable text padding , facilitating tasks like aligning console output or printing numbers with a fixed number of digits.
  • Service Worker Navigation Preload is now available as an Origin Trial, allowing developers to parallelize the network request for the main resource alongside service worker startup.
  • The Payment Request API can be made available inside an iframe by adding the allowpaymentrequest attribute.
  • PaymentMethodData now supports basic-card , so developers can refer to all card types with a single method identifier, rather than individual data types.
  • To simplify the migration from HTTP to HTTPS, stored credentials for HTTP forms are now transferred to the HTTPS version of the site, and the Credential Management API now supports filling credentials from matching subdomains.
  • The caret-color property enables developers to specify the color of the text input cursor.
  • To preserve consistency with other on<event> attributes, ongotpointercapture and onlostpointercapture are now part of the GlobalEventHandlers mixin.
  • Support is now available for text-decoration-skip: ink to make underlines skip descenders , the portion of letters that extend below the text's baseline.
  • New text-decoration properties are now available, allowing developers to specify visual effects such as line color and style.
  • The PresentationRequest constructor has been modified to accept multiple URLs via a sequence< DOMString > , in addition to the existing constructor that takes a single URL.
  • The new AudioContext.getOutputTimestamp() method enables developers to synchronize DOMHighResTimeStamp and AudioContext.currentTime values.
  • AudioBufferSourceNode , OscillatorNode , and ConstantSourceNode now inherit from AudioScheduledSourceNode , consolidating functionality.
  • The new cancelAndHoldAtTime function cancels future AudioParam events with times greater than or equal to cancelTime , allowing developers to preserve the value of the scheduled time in a direct way.
  • Developers can now construct WebAudio-specific events such as OfflineAudioCompletionEvent and AudioProcessEvent .
  • To increase user security, Chrome's XSS Auditor now blocks entire suspicious pages by default, rather than selectively filtering out the suspected reflected XSS on the page.

Deprecations and interoperability improvements

Posted by Xi Han, Home Screen Heroine

Integrating Progressive Web Apps deeply into Android

In 2015, we added a new feature to Chrome for Android that allows developers to prompt users to add their site to the Home screen for fast and convenient access. That feature uses an Android shortcut , which means that web apps don’t show up throughout Android in the same way as installed native apps. For example, many developers have asked for their web app to show up in the app drawer section of the launcher. These differences can be confusing for users and prevent the experience from feeling as cohesive as it could.

In the next few weeks we’ll be rolling out a new version of this experience in Chrome beta. With this new version, once a user adds a Progressive Web App to their Home screen, Chrome will integrate it into Android in a much deeper way than before. For example, Progressive Web Apps will now appear in the app drawer section of the launcher and in Android Settings, and will be able to receive incoming intents from other apps. Long presses on their notifications will also reveal the normal Android notification management controls rather than the notification management controls for Chrome.

This new Add to Home screen feature is one more step in our journey to empower developers to build the best possible experience for their users, and we are committed to ensuring the same mechanisms for installing Progressive Web Apps are available to all browsers on Android.

Posted by Yaron Friedman, Add to Home screen aficionado
Q&A: Fontana Gruppo - Special Fasteners tightens up global operations with G Suite

January 31 2017


Open-sourcing Chrome on iOS!

Historically, the code for Chrome for iOS was kept separate from the rest of the Chromium project due to the additional complexity required for the platform. After years of careful refactoring, all of this code is rejoining Chromium and being moved into the open-source repository .

Due to constraints of the iOS platform, all browsers must be built on top of the WebKit rendering engine. For Chromium, this means supporting both WebKit as well as Blink , Chrome's rendering engine for other platforms. That created some extra complexities which we wanted to avoid placing in the Chromium code base.

Given Chrome's commitment to open-source code, we've spent a lot of time over the past several years making the changes required to upstream the code for Chrome for iOS into Chromium. Today, that upstreaming is complete, and developers can compile the iOS version of Chromium like they can for other versions of Chromium. Development speed is also faster now that all of the tests for Chrome for iOS are available to the entire Chromium community and automatically run any time that code is checked in.

We value the open source community and all of our contributors, and we're glad that Chrome for iOS can finally join in.

Posted by Rohit Rao, Upstream Angler
Announcing new enterprise-grade controls and visibility in G Suite

January 30 2017


Performance improvements in Chrome's rendering pipeline

Speed is one of Chrome’s four core principles, enabling web developers to provide users with faster, more engaging web experiences. While many components in the browser contribute to overall speed, the rendering pipeline is primarily responsible for ensuring websites display at 60 frames per second (fps), which feels fast and responsive to users. Over the last few months we’ve rolled out several performance improvements to Chrome’s rendering pipeline, making it even smarter about the work it completes. Chrome now more intelligently skips redundant tasks, chooses optimal rendering algorithms, and better utilizes system hardware, causing websites to load faster, run smoother, and use less power.

In order to display content at 60fps, Chrome has only 16ms to render each frame , including JavaScript execution, style, layout, painting, and pushing the resulting pixels to the user’s screen. Of that 16ms time budget, the less Chrome uses, the more time web developers have to run scripts, load content, and delight their users. Many of our recent improvements to the rendering pipeline focus on reducing the per-frame workload, rather than simply improving Chrome’s raw speed.

For example, when Chrome is preparing to paint pixels to the screen, it must first identify which elements on the page need to be redrawn and which can be copied from the previous frame’s cache. On highly dynamic pages with frequent DOM changes, this performance cost can add up quickly. To simplify this task, Chrome now tracks the draw commands generated for each element and can identify visually non-overlapping subsets. If one of these subsets hasn’t been modified, the entire block can be copied directly from the cache without any additional work. This optimization reduces the time it takes to paint a new frame to the screen by up to 35%.

Chrome also groups the pixels into tiles to enable smaller and faster updates to the screen. Previously, Chrome would redraw any of these tiles that had been modified by a DOM update, but this is only optimal if the majority of a tile’s area needs to be redrawn. If only a few pixels have changed, it’s faster to copy the entire tile from the previous frame and then update the new pixels. Chrome can now intelligently choose the redraw pipeline that will be faster, reducing tile redraw time by up to 40%.

Any update to the screen, such as the input cursor blinking, would previously require the whole tile to be re-rendered (left). When only a few pixels have changed, Chrome can now redraw only the modified region (right).

In addition to intelligently optimizing its workload, Chrome is now better at choosing how it completes that work given the underlying hardware. While video and canvas elements have been GPU accelerated for a long time , Chrome is constantly getting better at utilizing the GPU for more challenging rendering tasks. On Android, Mac, and Windows, Chrome now better utilizes GPU acceleration for complex site content rendering. This improves animation performance, input latency, and scroll smoothness for modern SVG and HTML5 pages.

There are many different dimensions to speed, and we’re committed to continually improving Chrome’s performance and enabling developers to optimize their user experience to hit 60fps. The rendering pipeline is only one piece of the puzzle, and we’ve got a lot more coming. Stay tuned as we continue taking deep dives into performance and steadily make the web faster and more responsive for all Chrome users.

Posted by Chris Harrelson, Painting Professional

January 26 2017


Reload, reloaded: faster and leaner page reloads

Reload has long been a staple feature of web browsers and kept its original behavior throughout the years, despite the changing landscape of web platform innovations, connectivity, and content consumption patterns. When reloading a page, browsers will check with the web server if cached resources are still usable, a process known as validation. This typically results in hundreds of network requests per page issued to dozens of domains. On mobile devices, the high latency and transient nature of mobile connections mean that this behavior can produce serious performance issues. In the latest version of Chrome, changes to page reload behavior produce reloads that are 28% faster and result in 60% fewer validation requests.

Users typically reload either because a page is broken or the content seems stale. The existing reload behavior usually solves broken pages, but stale content is inefficiently addressed by a regular reload, especially on mobile. This feature was originally designed in times when broken pages were quite common, so it was reasonable to address both use cases at once. However, this original concern has now become far less relevant as the quality of web pages has increased. To improve the stale content use case, Chrome now has a simplified reload behavior to only validate the main resource and continue with a regular page load. This new behavior maximizes the reuse of cached resources and results in lower latency, power consumption, and data usage.

Despite being a relatively minor change, the new behavior makes reloads up to 28% faster and consume less bandwidth and power. Furthermore, Facebook contacted us with data showing that Chrome was sending validation requests at three times the rate of other browsers. Thanks to the new reload behavior and some related changes, Facebook now reports 28% faster page reloads and 60% less validation requests from Chrome.

We hope this faster reload will come in handy whenever you want to get the latest content on your favorite website or quickly recover from a flaky connection in the subway.

Posted by Takashi Toyoshima, “Reloader Sensei”

January 19 2017

See how G Suite and DocuSign help real estate brokers close deals faster

December 13 2016


Introducing the WebVR API in Chrome for Android

Virtual Reality (VR) is rapidly growing in popularity, and now it's coming to the web. The power of the web is that it can allow VR to work across browsers and hardware, accessible via a single click. This enables VR developers to broadly reach users across multiple types of headsets with a single web app. Here’s how to get started.
Chrome 56 for Android is now available in beta, and web developers can sign up for an Origin Trial which enables the WebVR API and GamePad API extensions . The WebVR API provides access to the input and output capabilities of virtual reality devices such as Daydream View. It also provides access to the user’s position and orientation, so that web apps can render a stereoscopic 3D scene to the headset's display. The Gamepad API extensions provide access to input from motion controllers, such as the Daydream controller, and enables natural interactions in VR.
Origin Trials allow a developer to temporarily enable the feature for all Chrome users visiting their website. The WebVR API is still evolving and will undergo further changes based on developer feedback before being enabled by default for all pages. WebVR will be extended to desktop platforms and Google Cardboard in a future Chrome release, and several performance improvements are coming in Chrome 57.
To learn how to get started and build your first WebVR web app, visit the WebVR developer site for tutorials and samples. Join the conversation by giving feedback on the API or the Chrome implementation and joining the WebVR Slack channel .
Posted by Brandon Jones, Virtual Reality Plumber

December 09 2016


Roll-out plan for HTML5 by Default

Four months ago we announced that we’d be moving to HTML5 By Default to offer a safer, more power-efficient experience. As a reminder , this change disables Adobe Flash Player unless there’s a user indication that they want Flash content on specific sites, and eventually all websites will require the user’s permission to run Flash. To ensure a smooth transition, not all users and sites will be affected immediately. HTML5 by Default and the associated user prompts will be introduced gradually as follows.
The feature will be rolled out to users over a few months. HTML5 By Default will be enabled for 1% of users of Chrome 55 Stable in the next few days. The feature is also enabled for 50% of Chrome 56 beta users. With Chrome 56 stable in February, we plan to enable it for all users.
Starting in January users will be prompted to run Flash on a site-by-site basis for sites that they have never visited before. We want to avoid over-prompting users, so over time we’ll tighten this restriction using Site Engagement Index , a heuristic for how much a user interacts with a site based on their browsing activity. In October all sites will require user permission to run Flash.
More details, including specific Site Engagement Index thresholds, are available on the Flash Roadmap Page . Developers can find recommendations on how to test their Flash sites there as well. As sites transition from Flash to HTML5, this change will no longer affect them and the entire web will become faster, more secure and power-efficient.
Posted by Eric Deily, wrangler of the Default

December 08 2016


Chrome 56 Beta: “Not Secure” warning, Web Bluetooth, and CSS position: sticky

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

“Not Secure” warning for HTTP password and credit card pages

To help users browse safely, Chrome indicates connection security with an icon in the address bar. Historically, Chrome has not explicitly labelled HTTP connections as non-secure. Starting in version 56, Chrome will mark HTTP pages that collect passwords or credit cards as non-secure, as part of a long-term plan to mark all HTTP sites as non-secure. The feature will roll out gradually over the next few weeks.

To avoid being labeled insecure, sites should secure their traffic with HTTPS and follow general security guidelines .

Chrome ‘Not Secure’ warning appearing in the URL bar for a site with an HTTP connection  

Web Bluetooth

Sites can now interact with Bluetooth Low Energy (BLE) devices using the Web Bluetooth API o n A n d r o i d , C h r o m e O S , a n d Mac. The Web Bluetooth API uses the GATT protocol , which enables web developers to connect to bluetooth devices such as printers and LED displays with just a few lines of JavaScript. Web Bluetooth can also be combined with Physical Web beacons to discover and control nearby devices. To get started, check out these samples and demos on GitHub.  

An Android device connecting to a BLE-enabled heart rate monitor via the web ( source )

CSS position: sticky

Chrome now supports CSS position: sticky , a new way to position elements. A position: sticky element is relatively-positioned, but becomes position: fixed after the user reaches a certain scroll position.

Previously, building content headers that scrolled normally until sticking to the top of the viewport required listening to scroll events and switching an element’s position from relative to fixed at a specified threshold. This solution was difficult to synchronize, resulting in small visual jumps. Now, users can achieve the desired effect by simply positioning their elements as sticky .

Other features in this release
  • Showing and hiding the URL bar on mobile no longer resizes the initial containing block or elements sized with viewport units such as vh .
  • Text input elements such as <input type="text"> now have spell-checking enabled by default on Android devices with at least 512 MB of memory and a system dictionary.
  • The generic font family used to fit content within the UI has been standardized and renamed as system-ui on all platforms.
  • The new Referrer-Policy HTTP header allows sites to forward site traffic by URL without leaking the user’s session identifier or other private information.
  • KeyboardEvent.isComposing() allows sites to determine if the user is typing based on recent KeyboardEvents , without monitoring keyboard events directly.
  • Chrome for Android now sets the default preload attribute for videos to metadata on cellular connections, showing a preview image and time information to match other mobile browsers.
  • Chrome now supports TLS 1.3 and includes 1-RTT based on draft-18 .
  • Sites can use ImageBitmapRenderingContext to reduce memory consumption and compositing overhead by rendering pixel data in the form of an ImageBitmap .
  • Sites can respond to pinch gestures using the pinch-zoom CSS touch-action property.
  • ConstantSourceNode is a new audio source node that produces a constant output mixed with an AudioParam .
  • Two Web Audio ChannelSplitterNode Interface attributes are now read-only: channelCount , which is defined by numberOfOutputs in createChannelSplitter() , and channelCountMode , which is set to explicit.
  • PannerNode.rolloffFactor now clamps to the nominal range of a PannerNode’s distance model to describe the volume reduction rate as the source moves away from the listener.
  • window.prompt() will no longer focus its parent tab if the page is not currently in the foreground, and the dialog will be automatically dismissed.
  • To match behavior on Windows, Chrome Extensions can now override default search, startup, and homepage settings on Mac with the Chrome Settings Overrides API .
  • Support for FLAC is enabled within the FLAC and Ogg containers for the <audio> tag and decodeAudioData() .
  • OPUS can now be used with decodeAudioData() , expanding the variety of audio codecs supported by the WebAudio API .

Deprecations and interoperability improvements
  • The WebAudio API no longer includes the deprecated Doppler API, including speedOfSound , dopplerFactor , and setVelocity .
  • To improve standards conformance, RTCPeerConnection now accepts iceTransportPolicy as an RTCConfiguration parameter as well as iceTransports .
  • RTCPeerConnection is now available without a webkit prefix, though webkitRTCPeerConnection still remains.
  • Non-whitespace unicode control characters will now be rendered according to the specification , rather than being ignored.
  • The reflected-xss directive has been removed from Content Security Policy 2 since it was solely a wrapper for the X-XSS-Protection header and provided no additional functionality.
  • Support for the MediaStreamTrack.getSources() method has been removed in favor of MediaDevices.enumerateDevices() .
  • The CSP referrer directive is no longer supported in favor of the new Referrer-Policy header.
  • ShadowDOM’s slotchange events bubble, but no longer re-fires, at a slot 's assignedSlot .  
  • Legacy CBC-mode ECDSA cipher suites ECDHE_ECDSA_WITH_AES_128_CBC_SHA and ECDHE_ECDSA_WITH_AES_256_CBC_SHA have been removed in favor of modern ciphers such as ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 .
  • ECDSA with both SHA-1 and SHA-512 have been removed to reduce dependencies on SHA-1 and align with TLS 1.3's new ECDSA handling.
  • Chrome no longer allows opening of pop-ups during inputs which represent a touch scroll, such as touchstart and touchmove .
  • Sites will no longer initiate fetches for scripts with invalid type or language attributes, such as type="python" , unless triggered by declarative fetches using link preload .
  • MIDIMessageEvent.receivedTime has been deprecated in favor of Event.timeStamp , since Event.timeStamp now supports high-resolution monotonic time instead of epoch time.

Posted by Vincent Scheib, Web Bluetooth Orthodontist

November 16 2016


Chrome Dev Summit 2016: The Mobile Web Moves Forward

Last week at the 4th annual Chrome Dev Summit , we were excited to share a glimpse of what’s possible with over 1,000 developers in person, and thousands more on the livestream. Each year this is a time to hear what developers have been building, share our vision for the future of the web platform, and celebrate what we love about the web...

Reach of the web
As we've talked about before, one of the superpowers of the web is its incredible reach. There are now more than two billion active Chrome browsers worldwide, with many more web users across other browsers. The majority of these users are now on mobile devices, bringing new opportunities for us to explore as an industry.

Mobile browsers also lead the way for the internet’s newest users. Exclusively accessing the internet from mobile devices, users in emerging markets struggle with limited computing power, unreliable networks, and expensive data. For these users, native apps can be a poor match due to their large data and storage requirements. And, it’s these constraints that have resulted in the developing markets leading the charge when it comes to innovating on the web.


Instead, the web can fill these needs for all users through an experience we've been calling Progressive Web Apps (PWAs). These web apps provide the performance users have come to expect from their device, while also offering critical capabilities such as offlining, add-to-homescreen, and push notifications. We've been encouraged by the strong adoption of these capabilities, with push notifications recently exceeding 18 billion notifications per day across 50,000 domains.

Last year when we spoke about PWAs, things were just getting started. Now we're seeing the movement in full swing, with many large sites across the globe launching great new apps and feeling the success that PWAs can bring.


Alibaba.com, built a PWA and saw a 76% increase in conversion rates across browsers. The investment in the mobile web increased monthly active user rates on iOS by 14 percent. On Android devices where re-engagement capabilities like push notifications and Add to Homescreen were enabled, active user rates increased by 30 percent.

Another great example is The Weather Channel. Since launching a PWA they achieved an 80% reduction in load time and within three months, saw almost 1 million users opt in to receive web push notifications.

During the Summit, we also heard from Lyft , who shared their experience of building a PWA in less than a month, and using less than a quarter of the engineering support needed to build their native app. Learn more about our how partners are using PWA technologies to enhance their mobile web experience.

What can you do?
We also have a variety of tools, libraries, and APIs available to help you bring the benefits of PWAs to your site. For example, Chrome's DevTools provides assistance along every step of the development flow. DevTools has a ton of new features to help you build great mobile apps, such as network simulation, CPU throttling, and a PWA audit tool powered by Lighthouse .

For developers just beginning their web app or looking to rework an existing one, the Polymer App Toolbox provides a set of components and tools for easily building a Progressive Web App using web components. And Polymer 2.0 is right around the corner, making it easy to take advantage of the new Web Components v1 APIs shipping cross-browser and build mobile web apps with minimal overhead.

Finally, checkout can be a complicated process to complete and in the retail sector alone there are 66% fewer conversions on mobile than on desktop. With PaymentRequest , you can now bring a seamless checkout experience to your website with support for both credit cards and Android Pay , increasing odds for conversion.

Catch up
Finally, if you didn’t catch our live stream in real time, you can always check back on our YouTube channel for all the recordings or see the highlights from the event in 57 seconds .

Thanks for coming, thanks for watching, and most of all, thank you for developing for the web!

Posted by Darin Fisher, VP Engineering, Chrome

November 09 2016

Build data-rich presentations in seconds with integrated apps and the Slides API

November 07 2016

Gmail and Google Calendar get a whole lot better on iOS

November 04 2016


Here’s to more HTTPS on the web!

Security has always been critical to the web, but challenges involved in site migration have inhibited HTTPS adoption for several years. In the interest of a safer web for all, at Google we’ve worked alongside many others across the online ecosystem to better understand and address these challenges, resulting in real change. A web with ubiquitous HTTPS is not the distant future . It’s happening now, with secure browsing becoming standard for users of Chrome.

Today, we’re adding a new section to the HTTPS Report Card in our Transparency Report that includes data on how HTTPS usage has been increasing over time. More than half of pages loaded and two-thirds of total time spent by Chrome desktop users occur via HTTPS, and we expect these metrics to continue their strong upward trajectory.
Percentage pages loaded over HTTPS in Chrome

As the remainder of the web transitions to HTTPS, we’ll continue working to ensure that migrating to HTTPS is a no-brainer, providing business benefit beyond increased security. HTTPS currently enables the best performance the web offers and powerful features that benefit site conversions, including both new features such as service workers for offline support and web push notifications , and existing features such as credit card autofill and the HTML5 geolocation API that are too powerful to be used over non-secure HTTP.

As with all major site migrations, there are certain steps webmasters should take to ensure that search ranking transitions are smooth when moving to HTTPS. To help with this, we’ve posted two FAQs to help sites transition correctly, and will continue to improve our web fundamentals guidance .

We’ve seen many sites successfully transition with negligible effect on their search ranking and traffic. Brian Wood, Director of Marketing SEO at Wayfair, a large retail site, commented “we were able to migrate Wayfair.com to HTTPS with no meaningful impact to Google rankings or Google organic search traffic. We are very pleased to say that all Wayfair sites are now fully HTTPS.” CNET, a large tech news site, had a similar experience. “We successfully completed our move of CNET.com to HTTPS last month,” said John Sherwood, Vice President of Engineering & Technology at CNET. “Since then, there has been no change in our Google rankings or Google organic search traffic.”

Webmasters that include ads on their sites also carefully monitor ad performance and revenue during large site migrations. The portion of Google ad traffic served over HTTPS has increased dramatically over the past 3 years. All ads that come from any Google source always support HTTPS, including AdWords, AdSense or DoubleClick Ad Exchange; ads sold directly, such as those through DoubleClick for Publishers, still need to be designed to be HTTPS-friendly. This means there will be no change to the Google-sourced ads that appear on a site after migrating to HTTPS. Many publishing partners have seen this in practice after a successful HTTPS transition. Jason Tollestrup, Director of Programmatic Advertising for the Washington Post , “saw no material impact to AdX revenue with the transition to SSL.”

As migrating to HTTPS becomes even easier, we’ll continue working towards a web that’s secure by
default. Don’t hesitate to start planning your HTTPS migration today!

Posted by Adrienne Porter Felt and Emily Schechter, Chrome Security Team

October 31 2016


Making Chrome on Windows faster with PGO

Chrome is always looking for ways to speed up the web. Starting in Chrome 53, Chrome has started using Microsoft’s Profile Guided Optimization (PGO) technology to make Chrome up to 15% faster on Windows.

New tab page load time
14.8% faster
Page load (time to first paint)
5.9% faster
Startup time
16.8% faster
PGO impact on load and startup time

Chrome is a huge software project with more than a million functions in its source code. Not all functions are equal - some are called frequently, while others are rarely used.  PGO uses data from runtime execution that track which functions are most common to guide optimization.
To gather this data, the nightly build process now produces a special version of Chrome that tracks how often functions are used. PGO then optimizes those high-use functions for speed, in some cases increasing the binary size of those functions. To balance out that increase, PGO also optimizes less-used functions with smaller, though slightly slower code. These trade-offs result in higher overall performance, and a smaller overall code footprint.
PGO also optimizes the memory location of the code, moving rarely-used functions away from frequently-used ones in memory.  This results in more optimal use of the CPU instruction cache by avoiding caching of less-used code, increasing overall performance. There are many other tricks that PGO uses to make Chrome faster, and they add up to great results.
64-bit Chrome on Windows is using PGO as of version 53, and 32-bit Chrome is using it as of version 54.  Try out the latest version of Chrome to see the difference with PGO.
Posted by Sébastien Marchand, who is Pretty Good at Optimizing.

October 21 2016


Chrome 55 Beta: Input handling improvements and async/await functions

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

Input handling improvements

As usage of the mobile web grows, it is increasingly important for sites to react well to touch input. Historically, this meant handling MouseEvent and TouchEvent separately, which can be difficult to maintain. Chrome now enables unified input handling by dispatching PointerEvents . PointerEvents lead to more responsive pages, as they don’t block scrolling by default. To achieve the same performance with TouchEvent , pages can use passive event listeners .

Chrome also now supports two new ways to respond to input. The touch-action CSS property enables sites to react to gestures such as panning. For mouse buttons, the new auxclick input event type allows sites to manage the click behavior of non-primary buttons.   

Async and await functions

Asynchronous JavaScript can be difficult to reason about. Promises help avoid the nesting problem of callbacks, but Promise-based code can still be difficult to read when a site has large chains of asynchronous dependencies. Chrome now supports the async and await JavaScript keywords, allowing developers to write Promise-based JavaScript that can be as structured and readable as synchronous code.

Fetching a URL and logging the response using Promises:

function logFetch(url) {
  return fetch(url)
   . then (response => response.text())
   . then (text => {
   }). catch (err => {
     console.error( 'fetch failed' , err);

The same code using async and await:

async function logFetch(url) {
  try {
    const response = await fetch(url);
   console.log(await response.text());
  catch (err) {
   console.log( 'fetch failed' , err);

CSS automatic hyphenation

Formatting text to fill available space can be a challenge across devices and screen sizes. Chrome now supports CSS automatic hyphenation , one of Chrome’s most frequently requested layout features, on Android and Mac. CSS hyphenation allows the browser to hyphenate words when line-wrapping, improving the visual consistency of text blocks. Hyphenation support will be extended to other platforms in future releases.

A paragraph rendered with and without automatic hyphenation

Other features in this release

  • The once event listener option enables callbacks to be invoked only once before removing the event listener.
  • Sites can now mark web storage as persistent , preventing Chrome from automatically clearing storage for that site.
  • Cross-origin iframes now require a user gesture to start audio playback using the Web Audio API o n Android, matching the behavior of the <audio> and <video> elements .
  • The TLS stack now implements GREASE , a mechanism to help prevent problems with buggy TLS servers.
  • Developers can create a MediaStreamTrackEvent in an alternative way with its new JavaScript constructor.
  • RSA-PSS signature algorithms have been added to TLS to prepare for TLS 1.3 .
  • To improve load times and prevent failed navigations , cross-origin and parser-blocking scripts injected using document.write() will no longer load over 2G connections .
  • AudioNode constructors of the form new AudioNode(context, options) are now available, making it simpler to manage audio from scripts.
  • When the media player is too narrow to show every button, an overflow menu will appear to provide the hidden functionality to users.
  • Chrome media controls will now display a download button when the playback is associated with a file that can be downloaded.

Deprecations and interoperability improvements

  • BaseAudioContext will replace AudioContext in the Web Audio API to conform to spec.
  • CSS Clipping Path properties no longer require the webkit prefix.
  • The MediaStream constructor is now available without prefix alongside the existing webkitMediaStream .
  • Non-script MIME types will no longer trigger script execution.
  • <textarea maxlength=""> and <textarea minlength=""> have been updated to count each line break as one character, instead of two.
  • The webkit prefix has been removed from the imageSmoothingEnabled property of CanvasRenderingContext2D .

Posted by Dan Ehrenberg, Asynchronous Adventurer

October 18 2016


Canary channel for Chrome on Android

Chrome supports multiple release channels with varying degrees of stability and support. The Canary channel ships the most bleeding edge version of Chrome possible. It is primarily intended to be used by developers and early adopters to test recent Chromium changes, but anyone can install it and give it a try. Previously the Canary channel was only available on Windows and Mac, and it is now available for Android as well.

Just like the Canary channel for other platforms, new versions are built from the most recent code available and often contain a variety of new features, enhancements, and bug fixes. These builds are shipped automatically with no manual testing, which means that the build can be unstable and may even stop working entirely for days at a time. However, the goal is for Canary to remain usable at all times, and the Chrome team prioritizes fixing major issues as quickly as possible.

Initially, builds will ship every weekday. In the future new builds may also be available on weekends. The frequency of builds means that keeping the app updated will consume a lot of data, typically more than 100MB per week. This is especially important for phones set to update native apps over cellular data.

We hope the Canary channel will be useful when developing and testing changes for Chrome on Android. If you encounter any bugs, please help us by reporting them .

Posted by Alex Mineer, APK Administrator & Bug Basher

September 15 2016


Chrome 54 Beta: Custom Elements V1, BroadcastChannel, and media platform improvements

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

Custom Elements V1
Complex user interfaces often require a large amount of HTML. Most languages allow developers to create their own components built on top of language primitives to mitigate this kind of verbosity. Custom elements allow developers to create their own custom HTML tags , and define the new element’s API and behavior in JavaScript. This enables a browser-native way to build reusable, interoperable components.

Chrome 54 provides support for the latest custom elements V1 spec , which is broadly agreed-upon by major browser vendors. Chrome will also continue to support the V0 API until enough developers have moved to V1.

It is not uncommon for desktop users to have multiple windows or tabs open simultaneously. Some sites utilize this behavior, such as web editors that open documents in their own tabs. Historically, communicating between those tabs has been difficult. BroadcastChannel is a new one-to-many messaging API between windows, tabs, iframes, web workers, and service workers. It allows scripts to establish named channels to send messages between browsing contexts of the same origin.

Media platform improvements on Chrome for Android
Media is an increasingly large and important part of the browsing experience on mobile devices that requires fluidly utilizing the entire screen. Developers can now use Element.requestFullScreen() to trigger full screen mode after a screen orientation change in addition to after a user gesture. This allows experiences like rotate-to-fullscreen for media players.  

In addition to fullscreen improvements, Chrome on Android now persists the media notification of a backgrounded HTMLVideoElement , allowing a user to continue playing videos while they aren’t visible. Developers can detect background video playback by using the Page Visibility API .

Playing background videos in Chrome 54.

Other features in this release

Deprecations and interoperability improvements
  • To match behavior in other browsers, embedded YouTube Flash players will be rewritten by Chrome to use the HTML5 embed style, improving performance and security on Chrome Desktop.
  • CacheQueryOptions now conforms to spec across all CacheStorage methods.
  • initTouchEvent has been removed in favor of the new TouchEvent() constructor.
  • SVGZoomEvent has been removed as it is no longer part of the SVG 2.0 spec.
  • SVGSVGElement.currentView , SVGSVGElement.useCurrentView , SVGViewSpec interface, and SVGSVGElement.viewport have been removed as they are no longer part of the SVG 2.0 spec .
  • SVGTests.requiredFeatures attribute has been deprecated since it no longer provides useful functionality in the SVG 2.0 spec.
  • SVGElement now supports the dataset property.
  • The KeyEvent.keyIdentifier field has been removed in favor of the KeyboardEvent.key field.
  • window.external.IsSearchProviderInstalled() and AddSearchProvider() are now no-ops, since they are unsupported in most other browsers.

Posted by Marijn Kruisselbrink, Broadcast Buccaneer

September 14 2016

Better emails, tailored to all your devices
Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!