A before and after comparison of a repeat visitor loading a site that uses Service Workers.
Unlike other web technologies, the lifetime of a service worker is independent of the page that installed it. This lays the foundation for a new class of web applications with rich background capabilities. For example, future APIs like Push and Background Sync could do their work even after the page is closed, provided the user has given permission.
This release includes two new APIs for use only within service workers. The Fetch API allows service workers to make network requests—including cross-origin—and return the responses to pages they control. The Cache API can save fetched responses and then return them directly the next time the same resource is requested, bypassing the latency-prone network and the eviction-prone HTTP cache.
These APIs are still under active development and we are committed to keeping our implementation in sync with the specifications as they evolve. This release supports a subset of the Cache API, but developers can use a polyfill for full compatibility. If you’re interested in more in-depth information, check out HTML5 Rocks or our collection of useful service worker “recipes.” Other updates in this release
This release brings support for the new directives introduced in Content Security Policy (CSP) Level 2.
The new reportValidity method causes Chrome to draw the user’s attention to form fields with validation errors, saving developers from needing to implement this feature manually in JavaScript.
Chrome now supports the minlength attribute, a validation feature that allows developers to declare a lower bound on the number of characters a user can input.
Thanks to a collaboration with Intel's Open Source Technology Center, Chrome on Mac now uses HarfBuzz for text shaping which improves performance and rendering of non-Latin text, brings new optimizations, and unifies the font system across all platforms.
Noto supports major living languages such as English, Russian, Greek, Arabic, and Hebrew, as well as widely supported languages such as Cherokee and Sinhala, and even ancient languages like Egyptian hieroglyphics and Imperial Aramaic. The ultimate goal is for Noto to support every character for every language in the world—which will make tofu a thing of the past.
Noto has many advanced features:
Pan-CJK: Simplified and Traditional Chinese, Japanese, and Korean, all in a single font.
Seven weights: Thin, Light, DemiLight, Regular, Medium, Bold, Black. ChromeOS has default support for Regular and Bold, with more coming soon.
Free and open source: Freely available for everyone under the Apache License, v2.0.
Comprehensive character coverage: Covers all the CJK Ideographs in the Unicode Basic Multilingual Plane and a few hundred Ideographs in Unicode Plane 2. Also covered are over twelve thousand Korean Hangul characters with full support for Old Hangul. The total number of glyphs in each font instance is exactly 65,536, the maximum number of glyphs allowed by the OpenType font specification.
Region-appropriate glyph forms: CJK-shared ideographic characters follow region writing conventions to look appropriate to Chinese, Japanese, and Korean users.
Harmony: Noto Sans CJK and all other members of the Noto family are visually compatible with Noto Sans for English, so that text mixing English with another language looks harmonious.
In ChromeOS, Noto is now the default “sans serif” font. Developers that want to use Noto on platforms other than ChromeOS can load them as web fonts from Google Fonts: Early Access.
Although Noto's Latin, Greek, and Cryllic (LGC) characters are designed to harmonize with the CJK characters, developers might still want to use more familiar fonts for the LGC text. To support that, Noto is available in different subsets including Japanese, Korean, Simplified Chinese, Traditional Chinese, and all of CJK. Developers can then use CSS's font fallback mechanism to specify a LGC font ahead of a Noto Sans subset.
For example, if you're targeting devices that don't have Noto installed, want to use Arial for LGC characters, and want to use Noto for Japanese characters, you can include the following in your stylesheet:
The Topeka Android app uses an embedded Crosswalk WebView to achieve smooth performance even on older versions of Android, enabling a full fidelity material design UI with fluid animations and no polyfills. Crosswalk is now readily available through the Chrome Apps for Mobile tooling and should be used with an understanding of its advantages and tradeoffs.
Using Chrome Apps, you can now build performant and capable applications that target desktop, Android, and iOS devices. To get started, take a look at our documentation. As always, we welcome your feedback on Stack Overflow and our G+ Developers page.
Posted by Michal Mocny, Chrome Apps for Mobile Engineer and Mobile Magic Maker
Now, you can turn on Device Mode right next to the "inspect element" icon. Once enabled, it automatically emulates a mobile viewport, along with complete emulation of touch events. You can test various viewport sizes easily with the large drag handles instead of resizing the whole browser window. You can select from popular device presets to automatically set viewport, touch, user agent and screen density settings in one fell swoop.
Every media query gets represented visually, so you can correlate your breakpoints with the viewport. Clicking one resizes the viewport, making it easier to iterate on your associated styles. If you want to edit the media queries themselves, right-click and jump to the line of CSS where it's defined.
Lastly, device emulation needs to accurately represent the connectivity of your mobile users. For example, a 3G connection significantly limits the experience of your website compared to your speedy office WiFi. The DevTools can now help you emulate the network conditions (both throughput and latency) of connectivity like EDGE, 3G, 4G – and even go offline.
While typical system-wide network conditioning throttles everything, DevTools will only throttle the current tab. This enables you to take your app offline and try out AppCache and Service Worker scenarios, and meanwhile browse documentation in another tab.
Please try out Device Mode your development workflow and let us know what you think. And if you're hungry for more DevTools goodness, check out my Google I/O 2014 talk: Developing Across Devices.
Posted by Paul Bakaus, Developer Advocate and Device Diviner
Chrome 40 (Branch point 7 November 2014; Stable after holiday season)
Sites with end-entity certificates that expire between 1 June 2016 to 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.
Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “neutral, lacking security”.
The current visual display for “neutral, lacking security” is a blank page icon, and is used in other situations, such as HTTP.
Chrome 41 (Branch point in Q1 2015)
Sites with end-entity certificates that expire between 1 January 2016 and 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.
Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “affirmatively insecure”. Subresources from such domain will be treated as “active mixed content”.
The current visual display for “affirmatively insecure” is a lock with a red X, and a red strike-through text treatment in the URL scheme.
Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.
Posted by Chris Palmer, Secure Socket Lover and Ryan Sleevi, Transport Layer Securer
64-bit Chrome offers many benefits for speed, stability and security. Our measurements have shown that the native 64-bit version of Chrome has improved speed on many of our graphics and media benchmarks. For example, the VP9 codec that’s used in High Definition YouTube videos shows a 15% improvement in decoding performance. Stability measurements from people opted into our Canary, Dev and Beta 64-bit channels confirm that 64-bit rendering engines are almost twice as stable as 32-bit engines when handling typical web content. Finally, on 64-bit, our defense in depth security mitigations such as Partition Alloc are able to far more effectively defend against vulnerabilities that rely on controlling the memory layout of objects. At this point 64-bit will remain opt-in, so to take advantage of the improvements click on the new “Windows 64-bit” link on the Chrome download page. Currently, the only significant known issue is the lack of 32-bit NPAPI plugin support. The 32-bit channel will remain fully supported for the foreseeable future and we will continue to support 32-bit plugins until NPAPI is removed from Chrome. We encourage you to give 64-bit Chrome a try. We’re looking forward to hearing your feedback so we can continue to make Chrome the fastest, most secure and stable browser. Posted by Will Harris, Software Engineer and Embiggener of Bits
In this release we're also adding support for the <dialog> HTML5 element, which enables developers to create styled dialog boxes in their web applications and control them via a JavaScript API. For more details, check out some code samples and see <dialog> in action. The <dialog> element is a better-designed alternative to showModalDialog(), which is now disabled as we recently announced.
Other updates in this release
The Web Cryptography JavaScript API is enabled by default starting in Chrome 37, allowing developers to perform cryptographic operations such as hashing, signature generation/verification, and encryption.
Subpixel font scaling is now supported, which enables smooth animations of text between font sizes.
TouchEvent co-ordinates are now doubles instead of longs, enabling higher-fidelity touch interactions on high-DPI displays.
Last summer, we launched Chromecast, a small, affordable device that lets you cast online video, music and anything from the web to your TV. Today at Google I/O, we announced Android TV, the newest form factor to the Android platform, and a way to extend the reach of Google Cast to more devices, like televisions, set-top boxes and consoles.
Check out Coming to a Screen Near You for some details on everything we’re doing to make your TV the place to be.
For developers though--sorry, you don’t get to unwind in front of the TV. We need you to get to work and help us create the best possible TV experience, with all of the new features announced at I/O today.
Get started with Android TV
In addition to Google Cast apps that send content to the TV, you can now build immersive native apps and console-style games on Android TV devices. These native apps work with TV remotes and gamepads, even if you don’t have your phone handy. The Android L Developer Preview SDK includes the new Leanback support library that allows you to design smoother, simpler, living room apps.
And this is just the beginning. In the fall, new APIs will allow you to cast directly to these apps, so users can control the app with the phone, the remote, or even their Android Wear watch. You’ll also start seeing Android TV set-top boxes, consoles and televisions from Sony, TP Vision, Sharp, Asus, Razer and more.
Help more users find your Google Cast app
We want to help users more easily find your content, so we’ve improved the Google Cast SDK developer console to let you upload your app icon, app name, and app category for Android, iOS and Chrome. These changes will help your app get discovered on chromecast.com/apps and on Google Play.
Additional capabilities have also been added to the Google Cast SDK. These include: Media Player Library enhancements, bringing easier integration with MPEG-DASH Smooth Streaming, and HLS. We’ve also added WebAudio & WebGL support, made the Cast Companion Library available, and added enhanced Closed Caption support. And coming soon, we will add support for queuing and ID delegation.
Ready to get started? Visit developer.android.com/tv and developers.google.com/cast for the SDKs, style guides, tutorials, sample code, and the API references. You can also request an ADT-1 devkit to bootstrap your Android TV development.
By Dave Burke and Majd Bakar, Engineering Directors and TV Junkies
Once you’ve installed the Chrome Apps & Extensions Developer Tool, it will start locally auditing your extensions and apps as you use them. For each app or extension, you can see historical activity over the past few days as well as real-time activity by clicking the “Behavior” link. The tool highlights activities that involve your information, such as reading website cookies or modifying web sites, in a privacy section. You can also search for URLs to see if an extension has modified any matching pages. If you’re debugging an app or extension, you can use the “Realtime” tab to watch the stream of API calls as an extension or app runs. This can help you track down glitches or identify unnecessary API calls.
Whether you’re a Chrome power user or a developer testing an extension, the Chrome Apps & Extensions Developer Tool can give you the information you need to understand how apps and extensions affect your browsing.
Posted by Adrienne Porter Felt, Software Engineer and Extension Tinkerer
Deprecation has proceeded as scheduled. As of September 23rd, 2013, the Chrome Web Store no longer accepts NPAPI-based Apps and Extensions. Webpage-instantiated NPAPI plug-ins have been blocked by default since January 2014 using the infobar UI. NPAPI support was removed from Linux in Chrome 35.
To further prepare users and developers for complete removal, we’ll be making two more updates in the coming weeks. Starting today, the Chrome Web Store will no longer show NPAPI-based Apps and Extension on the home page, search results, and category pages. In Chrome 37, webpage-instantiated NPAPI plug-ins will be blocked using the harder-to-bypass page-action blocking UI.
Most use cases that previously required NPAPI are now supported by JavaScript-based open web technologies. For the few applications that need low-level APIs, threads, and machine-optimized code, Native Client offers the ability to run sandboxed native code in Chrome. To help ease the transition from NPAPI, NaCl recently exposed two new Pepper APIs for media playback and processing. The MediaStreams API enables low latency multimedia playback, and the Hardware Decode API enables efficient video decoding.
For more information, please see the developer NPAPI deprecation guide. We look forward to the transition to a safer, more mobile-friendly web.
Posted by Justin Schuh, Software Engineer and Plug-in Retirement Planner
