If you missed the Day 1 keynote this year, it was all about the open web. There were some amazing demos from Mugtug, TweetDeck, Adobe, and Sports Illustrated demonstrating the full potential of HTML5. There was a preview of WebM/VP8, a high-quality, open, and web-optimized video format. We saw the announcement of the Chrome Web Store, which later this year will provide a new and exciting channel for developers to distribute their web apps and reach new users. We also launched the Google Font API, which allows you to add high-quality web fonts to any web page. Lastly, there were all of the great Chrome sessions. Videos have been posted on the Google I/O website:
You can try out these features by launching a Dev-channel version of Google Chrome with the --enable-experimental-extension-apis flag and adding the ‘experimental’ permission in your manifest.json file. Please keep in mind that these features are still under development and are not 100% stable yet.
Upcoming developer events
For those of you based in New York, there’s an upcoming Chrome Extensions hackathon in our local office on June 10, 2010. We also have a five day DevFest starting June 28, 2010 in Sydney, Australia. Google Chrome will be featured on Wednesday, June 30. Stay tuned for more details!
For the latest news and upcoming developer events, subscribe to this blog and follow us on Twitter @ChromiumDev.
Posted by Eric Bidelman, Google Chrome Developer Relations
If you are a developer interested in learning more about Google Cloud Print, first review our documentation then keep an eye on check-ins to the chromium.org project. Those who have been following know that we’ve already added preliminary printing support to Chromium OS via Google Cloud Print and our proxy (which enables legacy printers to work with the service) now runs on Windows, Mac, and Linux. Posted by Mike Jazayeri, Group Product Manager
The Scripts panel now allows editing JavaScript without having to reload the page. Just double-click on the line in the function body while debugging and make your changes. We’ll patch the underlying optimized machine code at run-time and continue the execution. [video]
CPU profiler captures the state of your app at a rate of 1,000 samples per second without modifications to the running optimized machine code. The resulting tree view makes it easy to find out where to focus efforts on speeding up the web app. [video]
The new Timeline panel provides a simple view of the AJAX application execution. It records everything that happens in the browser from JavaScript execution to styles re-calculations and then visualizes it in a simple waterfall with timing information and traces to the source code. See the demo fragment at [video].
The improved Heap profiler can take snapshots of the JavaScript heap, visualize and compare them. This makes finding and fighting memory leaks a much easier task. See the demo fragment at [video].
We also covered a number of general Inspector improvements in the WebKit blog recently. Watch them live in the DevTools panel walk through from the I/O video.
We welcome feedback: to submit a bug or feature request please use the Chromium issue tracker and mention DevTools in the summary.
We hope you like the new improved Google Chrome Developer Tools. Note that some of the features above are only available on Google Chrome’s Dev Channel at this moment. For more info please check out the DevTools site.
We initially implemented WebSocket in WebKit, which has been available in WebKit nightly builds and in Google Chrome. The initial implementation was based on draft-hixie-thewebsocketprotocol-75. Early adopters were able to start developing web apps using WebSocket on real browsers, and provide feedback about the WebSocket specification.
Based on community feedback, the WebSocket specification has been updated to draft-ietf-hybi-thewebsocketprotocol-00 (also known as draft-hixie-thewebsocketprotocol-76).
This version relaxes requirements on handshake messages to make it easier to implement with HTTP libraries, and introduces nonce-based challenge-response to protect from cross protocol attacks. These changes make it incompatible with draft-hixie-thewebsocketprotocol-75; a client implementation of -75 can’t talk with a server implementation of -76, and vice versa.
Developers should be aware that starting from WebKit nightly build r59903 and Chrome 6.0.414.0 (r47952), the client will talk to a server using -76 version of the protocol, so it will fail to open WebSocket connections with a WebSocket server based on draft-hixie-thewebsocketprotocol-75. Since -75 version of the protocol is obsoleted and no longer supported in future version of browsers, to support new clients you need to update the server implementation. (Note that Chrome 5 uses -75 version of protocol).
The WebSocket protocol is still actively being changed. Until there is more consensus, we will continue to update our implementation to follow the latest draft of specification, rather than worrying about breaking changes.
We’re more than happy to hear your feedback, and encourage you to file any bugs you find on our issue tracker.
Posted by Fumitoshi Ukai (鵜飼文敏), Software Engineer
Documenting Google Chrome’s use of promotional tags and tokens was a good start, but we wanted to take this transparency a step further. Our goal was to not only show you exactly how we were sending distribution information, but also what information was included and how it was generated.
Today, we’ve open-sourced the code that generates the RLZ parameter that sometimes appears in Google search queries. We’ve made the RLZ library its own project on the Google Code site, since this is the same library that is used in other Google products. This is analogous to how we opened Omaha, the Google Updater technology, as its own open-source project.
Chromium will also continue to exist as it always has, without any RLZ library included. And, you can still download a Google Chrome with no RLZ behavior at www.google.com/chrome. But now that RLZ is open, Google Chrome distributed through promotional means will include this open-source implementation of RLZ.
It is our hope that we are not only opening up a previously-closed part of Google Chrome and providing better transparency, but that we’re also offering up potentially useful code to others who may use it in their own projects.
We know this is just a small step, but we think that the RLZ project will provide better transparency and value to the community. We want to hear what you think, so please keep the feedback coming!
Posted by Roger Tawa, Software Engineer, and Glenn Wilson, Product Manager
