Chrome 38 Beta: New primitives for the next-generation web

Thursday, August 28, 2014

Today’s Chrome Beta channel release includes a ton of new primitives and APIs to simplify development and give developers more control over their web applications. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux, and Chrome OS.

New HTML element: <picture>

This release adds support for the new <picture> element thanks to the hard work of community contributor Yoav Weiss, who was able to dedicate his time to implementing this feature in multiple rendering engines because of a successful crowdfunding campaign that raised 50% more than its funding goal.

The <picture> element takes the concept of responsive design, previously solved by sending duplicate resources to the client, and bakes an elegant solution right into the web platform. It allows developers to list multiple versions of images that may be appropriate for the browser to display based on screen size, pixel density, or other factors.


<picture>
    <source media="(min-width: 45em)" srcset="large.jpg">
    <source media="(min-width: 32em)" srcset="med.jpg">
    <img src="small.jpg" alt="The president giving an award.">
</picture>


New JavaScript features

Chrome 38 also enables by default several new JavaScript language features from the draft ECMAScript 6 (ES6) specification. Additions include:
  • Maps and sets, two highly-requested data structures which make storing and interacting with data simpler and more rational.
  • Iterators now provide an easy and extensible way to iterate over sequenced data types such as arrays and strings, as well as the new maps and sets.
  • Symbols, which help prevent object properties from unintentionally interfering with each other.
  • Math functions such as Math.sign and Math.log10, which prevents developers from having to re-implement these functions and provides the performance boost of built-in functions. Take a look at the full list of new functions.
Future releases of Chrome will contain even more ES6 features as the specification matures. Stay posted!

Other updates in this release
  • The Network Information ("NetInfo") API is now enabled, giving web applications access to the current type of network on a device running Android, iOS, or Chrome OS. This could allow an app to only do data-intensive activities such as syncing when connected to a Wi-Fi connection.
  • The addition of the Screen Orientation API allows developers to not only detect whether a device is in portrait or landscape mode, but also lock the screen orientation while a user is within that app.
  • The CSS value "image-rendering: pixelated" is now supported, which allows scaled images to appear to be composed of very large pixels. Example use cases include high-performance display of zoomed photos in image editing software without large bandwidth or load time costs.
  • The Encoding API enables the encoding and decoding of data from binary streams, such as converting between a raw ArrayBuffer and a string.
  • The new File interface allows developers to create and interact with File objects in the same way as Blob objects.
As always, visit chromestatus.com/features for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates!

Posted by Andreas Rossberg, Senior Symbolic Software Engineer

Mac Chrome: When I’m Sixty-Four (Bits)

Thursday, August 28, 2014

On the heels of Tuesday’s release of 64-bit Chrome for Windows, all Mac Chrome users on the beta channel will be updated to a new 64-bit version of Chrome 38. Previously, Chrome was a 32-bit app on Macs. While doubling the number of bits won’t make things twice as good, it does allow us to make a number of speed and security improvements.

64-bit Chrome has become faster as a result of having access to a superior instruction set, more registers, and a more efficient function calling convention. Improved opportunities for ASLR enhance this version’s security. Another major benefit of this change comes from the fact that most programs on a modern Mac are already 64-bit apps. In cases where Chrome was the last remaining 32-bit app, there were launch-time and memory-footprint penalties as 32-bit copies of all of the system libraries needed to be loaded to support Chrome. Now that Chrome’s a 64-bit app too, we expect you’ll find that it launches more quickly and that overall system memory use decreases.

Because of this change, Chrome for Mac will no longer support 32-bit NPAPI plugins, although their 64-bit counterparts are supported. Users shouldn’t notice any changes, because most major plugins are available in both 32-bit and 64-bit form, and many major websites have been switching from NPAPI towards more modern HTML5 APIs. This is also a good time to remind everyone that NPAPI support will be removed from Chrome later this year.

Nearly every Mac user has a computer capable of running this 64-bit version, so we’re automatically updating all Mac Chrome beta channel users. Those few users with first-generation Intel Macs will miss out on the fun, but as we bid them farewell, we’ll remind them that they’ll still be able to run the latest version on the stable channel, Chrome 37.

You can check to see if the Chrome you’re running is a 64-bit version by checking Chrome’s About page (chrome://help) and looking next to the version number. If it says “64-bit” there, that’s a sure sign that you’re running one of these new builds. We hope that this is the only visible difference that you’ll find between the old 32-bit and new 64-bit versions, but in case you find anything amiss during the beta period, please let us know.

Posted by Mark Mentovai, Software Engineer and Register Doubler

64 bits of awesome: 64-bit Windows Support, now in Stable!

Tuesday, August 26, 2014

Today, after a successful experiment with Chrome 64-bit Windows in our Dev and Canary channels in June, 64-bit Windows support is coming to Chrome Stable with the release of Chrome 37.

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

Chrome 37 Beta: DirectWrite on Windows and the <dialog> element

Thursday, July 17, 2014

Today’s Chrome Beta channel release includes a slew of new developer features to help you make richer, faster and more compelling web content and apps, especially for mobile devices. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux, and Chrome OS.

DirectWrite on Windows

Chrome 37 adds support for DirectWrite, an API on Windows for clear, high-quality text rendering even on high DPI displays. Before DirectWrite, Chrome used the Graphics Device Interface (GDI) to render text. GDI dates back to the mid-80's and reflects the engineering tradeoffs of that time, particularly for slower, lower-resolution machines. The switch to DirectWrite has been a top user request for years, and required extensive re-architecting and streamlining of Chrome's font rendering engine.

Some users should begin seeing better-looking fonts and increased rendering performance as we roll out DirectWrite, with no changes required by web developers. Assuming everything goes smoothly, all users will experience the improvements by the Chrome 37 stable release.

Compare the below screenshots, taken with and without DirectWrite enabled.



New HTML element: <dialog>

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.
  • CSS cursor values "zoom-in" and "zoom-out" are now unprefixed.
  • The number of cores on a physical machine can now be accessed by navigator.hardwareConcurrency.
  • The user's preferred languages are now accessible by navigator.languages, and the languagechange event is fired when this is updated.
  • The CSS Shapes Module allows developers to define non-rectangular text wrapping boundaries around floated elements.
  • NPAPI deprecation continues according to our previously-announced plan with a harder-to-bypass blocking UI
  • The default monospace font on Windows is now Consolas instead of Courier New.
As always, visit chromestatus.com/features for a complete overview of Chrome’s developer features,  and circle +Google Chrome Developers for more frequent updates!

Posted by Emil A Eklund, Software Engineer and Senior Blog DirectWriter



Disabling showModalDialog

Wednesday, July 16, 2014

The web platform has evolved organically over the past two decades, slowly growing new capabilities and APIs. Many features that are added are great ideas that enable web developers to make even better applications. But some APIs turn out, in retrospect, to be mistakes. Over time, the platform accretes more bad APIs, which makes it harder to add new browser features, confuses web developers, and even introduces security bugs. showModalDialog is a bad API that we deprecated earlier this year, and in Chrome 37 we will disable support for it by default.

showModalDialog was first introduced in Internet Explorer 4 and although it was never formally standardized, over time most other browsers added support for it. It allows applications to show a dialog of HTML content that freezes all other content while showing. showModalDialog is not a commonly used API: based on our usage counters, less than 0.006% of pages use it.

Unfortunately, showModalDialog's unique ability to freeze content is now widely regarded as a mis-feature in terms of user experience, code complexity, and security. From a usability perspective, showModalDialog rudely demands that you interact with it by freezing all of your other tabs—even ones from other sites. showModalDialog also requires complex and hard-to-maintain code scattered throughout the codebase. This complexity complicates the behavior of new web features like Mutation Observers, Object.observe, and Promises. It also makes showModalDialog a source of a disproportionate number of bugs, including serious security vulnerabilities. It is for these reasons that we decided to turn off showModalDialog by default in the next version of Chrome.

Although very few sites use showModalDialog, the small minority that do—disproportionately enterprise sites—have come to rely heavily on it. In order to give these sites more time to update, we have added a temporary Enterprise Policy setting to re-enable showModalDialog. In May 2015 this setting will be removed and showModalDialog will be completely removed from Chromium. Affected sites should begin work to update their sites as soon as possible.

Although it can be difficult, sometimes the only way to go forward is to leave the past behind. Removing bad APIs will help us make the web a more consistent and capable platform for both developers and users.

Posted by Adam Barth, Software Engineer

Migrate Your Legacy Packaged Apps to Chrome Apps

Monday, June 30, 2014

In 2010, we created packaged apps to fill a missing link between extensions and hosted apps. They look the same as a hosted app to the user, but under the covers, they are more like traditional extensions. Over time, we realized that a clearer separation between the Chrome browser and apps was necessary, both for security reasons and to conform to user expectations. We launched the next generation of Chrome Apps, a new version of packaged apps, last year to address those issues, and today we're announcing the deprecation of legacy packaged apps.

Starting today, no new legacy packaged apps can be published in the Chrome Web Store. In December, all existing legacy packaged app listings will be removed from Chrome Web Store’s search and browse functions. Existing legacy packaged apps can be updated until Chrome stops loading them in June of 2015. Nothing will change for hosted apps or new packaged apps.

Developers are strongly encouraged to migrate their legacy packaged apps to either Chrome Apps or extensions. To get started, check out our migration tutorial, and contact us on the chromium-apps forum or our G+ page with any questions.

Posted by Amanda Bishop, Product Manager


Cast Away with Android TV and Google Cast

Wednesday, June 25, 2014

[Cross-posted from the Google Developers Blog]


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