Friday, January 14, 2011

[Gd] More about the Chrome HTML Video Codec Change

| More

Chromium Blog: More about the Chrome HTML Video Codec Change

There has been a lot of discussion regarding this week’s announcement of upcoming changes to HTML video codec support in Chrome. The future of web video is an important topic, we welcome the debate, and want to address some of the questions raised.

Why is Google supporting WebM for the HTML <video> tag?

This week’s announcement was solely related to the HTML <video> tag, which is part of the emerging set of standards commonly referred to as “HTML5.” We believe there is great promise in the <video> tag and want to see it succeed. As it stands, the organizations involved in defining the HTML video standard are at an impasse. There is no agreement on which video codec should be the baseline standard. Firefox and Opera support the open WebM and Ogg Theora codecs and will not support H.264 due to its licensing requirements; Safari and IE9 support H.264. With this status quo, all publishers and developers using the <video> tag will be forced to support multiple formats.

This is not an ideal situation and we want to see a viable baseline codec that all browsers can support. It is clear that there will not be agreement to specify H.264 as the baseline codec in the HTML video standard due to its licensing requirements. Furthermore, we genuinely believe that core web technologies need to be open and community developed to enable the same great innovation that has brought the web to where it is today. These facts led us to join the efforts of the web community and invest in an open alternative, WebM.

Why didn’t you select H.264 as the baseline codec for the HTML <video> tag in Chrome?

We acknowledge that H.264 has broader support in the publisher, developer, and hardware community today (though support across the ecosystem for WebM is growing rapidly). However, as stated above, there will not be agreement to make it the baseline in the HTML video standard due to its licensing requirements. To use and distribute H.264, browser and OS vendors, hardware manufacturers, and publishers who charge for content must pay significant royalties—with no guarantee the fees won’t increase in the future. To companies like Google, the license fees may not be material, but to the next great video startup and those in emerging markets these fees stifle innovation.

But it's not just the license fees; an even more important consideration is the pace of innovation and what incentives drive development. No community development process is perfect, but it’s generally the case that the community-driven development of the core web platform components is done with user experience, security and performance in mind. When technology decisions are clouded by conflicting incentives to collect patent royalties, the priorities and outcome are less clear and the process tends to take a lot longer. This is not good for the long term health of web video. We believe the web will suffer if there isn't a truly open, rapidly evolving, community developed alternative and have made significant investments to ensure there is one.

Does this mean I will no longer be able to play H.264 videos in Chrome?

H.264 plays an important role in video and the vast majority of the H.264 videos on the web today are viewed in plug-ins such as Flash and Silverlight. These plug-ins are and will continue to be supported in Chrome. Our announcement was only related to the <video> tag, which is part of the emerging HTML platform. While the HTML video platform offers great promise, few sites use it today and therefore few users will be immediately impacted by this change.

Isn’t this just an effort by Google to control the web video format?

WebM is backed by many in the web community. Google views its role like any other community member and has no desire or intent to control the WebM format. Our goal is to see the HTML <video> tag become a first-class video platform. As with many other web platform efforts, we expect the majority of organizations and individuals contributing to WebM won’t be affiliated with Google or any single entity.

Developers have already created high-quality alternative (yet compatible) implementations of WebM, and we think that kind of choice is great for everyone.

Won’t this decision force publishers to create multiple copies of their videos?

Some have expressed concern that our announcement will force publishers and developers to maintain multiple copies of their content when they otherwise would not have had to. Google is among the largest publishers of video content in the world, and as such we are sympathetic to this concern. Remember, Firefox and Opera have never supported H.264 due to its licensing requirements, they both support WebM and Ogg Theora. Therefore, unless publishers and developers using the HTML <video> tag don’t plan to support the large portion of the desktop and mobile web that use these browsers, they will have to support a format other than H.264 anyway (which is why we are working to establish a baseline codec for HTML video). More broadly, given the proliferation of devices, platforms, and connectivity types used to access the web, most content providers already produce multiple versions of their videos to optimize for these devices. We’re confident that the rapid evolution of HTML video and WebM over the coming year will make the combination a compelling solution for content providers and developers and the proliferation of WebM capable devices will make their investments highly leveraged.

Bottom line, we are at an impasse in the evolution of HTML video. Having no baseline codec in the HTML specification is far from ideal. This is why we're joining others in the community to invest in WebM and encouraging every browser vendor to adopt it for the emerging HTML video platform (the WebM Project team will soon release plugins that enable WebM support in Safari and IE9). Our choice was to make a decision today and invest in open technology to move the platform forward, or to accept the status quo of a fragmented platform where the pace of innovation may be clouded by the interests of those collecting royalties. Seen in this light, we are choosing to bet on the open web and are confident this decision will spur innovation that benefits users and the industry.

Posted by Mike Jazayeri, Product Manager

Thursday, January 13, 2011

[Gd] Have Androids. Will Travel.

| More

Android Developers Blog: Have Androids. Will Travel.

[The first part of this post is by Reto Meier. —Tim Bray]

From c-base in Berlin to the Ice Bar in Stockholm, from four courses of pasta in Florence to beer and pretzels in Munich, and from balalikas in Moscow to metal cage mind puzzles in Prague - one common theme was the enthusiasm and quality of the Android developers in attendance. You guys are epic.

For those of you who couldn't join us, we're in the middle of posting all the sessions we presented during this most recent world tour. Stand by for links.

Droidcon UK

We kicked off our conference season at Droidcon UK, an Android extravaganza consisting of a bar camp on day 1 and formal sessions on day 2. It was the perfect place for the Android developer relations team to get together and kick off three straight weeks of Google Developer Days, GTUG Hackathons, and Android Developer Labs.

Android Developer Labs

The first of our Android Developer Labs was a return to Berlin: home to c-base (a place we never got tired of) and the Beuth Hochschule für Technik Berlin. This all day event cost me my voice, but attracted nearly 300 developers (including six teams who battled it out to win a Lego Mindstorm for best app built on the day.)

Next stop was Florence which played host to our first Italian ADL after some fierce campaigning by local Android developers. 160 developers from all over Italy joined us in beautiful Florence where the Firenze GTUG could not have been more welcoming. An afternoon spent with eager developers followed up by an evening of real Italian pasta - what's not to love?

From the warmth of Florence to the snow of Stockholm where we joined the Stockholm GTUG for a special Android themed event at Bwin Games. After a brief introduction we split into six breakout sessions before the attendees got down to some serious hacking to decide who got to bring home the Mindstorm kit.

Google Developer Days

The Google Developer Days are always a highlight on my conference schedule, and this year's events were no exception. It's a unique opportunity for us to meet with a huge number of talented developers - over 3,000 in Europe alone. Each event featured a dedicated Android track with six sessions designed to help Android developers improve their skills.

It was our first time in Munich where we played host to 1200 developers from all over Germany. If there was any doubt we'd come to the right place, the hosting of the Blinkendroid Guinness World Record during the after-party soon dispelled it.

Moscow and Prague are always incredible places to visit. The enthusiasm of the nearly 2,500 people who attended is the reason we do events like these. You can watch the video for every Android session from the Prague event and check out the slides for each of the Russian sessions too.

GTUG Hackathons

With everyone in town for the GDDs we wanted to make the most it. Working closely with the local GTUGs, the Android and Chrome teams held all-day hackathon bootcamps in each city the day before the big event.

It was a smaller crowd in Moscow, but that just made the competition all the more fierce. So much so that we had to create a new Android app just for the purpose of measuring the relative volume of applause in order to choose a winner.

If a picture is a thousand words, this video of the Prague Hackathon in 85 seconds will describe the event far better than I ever could. What the video doesn't show is that the winners of "best app of the day" in Prague had never developed for Android before.

In each city we were blown away by the enthusiasm and skill on display. With so many talented, passionate developers working on Android it's hard not to be excited by what we'll find on the Android Market next. In the mean time, keep coding; we hope to be in your part of the world soon.

On To South America

[Thanks, Reto. This is Tim again. The South American leg actually happened before the Eurotour, but Reto got his writing done first, so I'll follow up here.]

We did more or less the same set of things in South America immediately before Reto’s posse fanned out across Europe. Our events were in São Paulo, Buenos Aires, and Santiago; we were trying to teach people about Android and I hope we succeeded. On the other hand, I know that we learned lots of things. Here are a few of them:

  • Wherever we went, we saw strange (to us) new Android devices. Here’s a picture of a Brazilian flavor of the Samsung Galaxy S, which comes with a fold-out antenna and can get digital TV off the air. If you’re inside you might need to be near a window, but the picture quality is fantastic.

  • There’s a conventional wisdom about putting on free events: Of the people who register, only a certain percentage will show up. When it comes to Android events in South America, the certain-percentage part is wrong. As a result, we dealt with overcrowded rooms and overflow arrangements all over the place. I suppose this is a nice problem to have, but we still feel sorry about some of the people who ended up being overcrowded and overflowed.

  • Brazilians laugh at themselves, saying they’re always late. (Mind you, I’ve heard Indians and Jews and Irish people poke the same fun at themselves, so I suspect lateness may be part of the human condition). Anyhow, Brazilians are not late for Android events; when we showed up at the venue in the grey light of dawn to start setting up, they were already waiting outside.

  • I enjoyed doing the hands-on Android-101 workshops (I’ve included a picture of one), but I’m not sure Googlers need to be doing any more of those. Wherever you go, there’s now a community of savvy developers who can teach each other through the finer points of getting the SDK installed and working and “Hello World” running.

  • Brazil and Argentina and Chile aren’t really like each other. But each has its own scruffy-open-source-geek contingent that likes to get together, and Android events are a good opportunity. I felt totally at home drinking coffee with these people and talking about programming languages and screen densities and so on, even when we had to struggle our way across language barriers.

The people were so, so, warm-hearted and welcoming and not shy in the slightest and I can’t think about our tour without smiling. A big thank-you to all the South-American geeks and hackers and startup cowboys; we owe you a return visit.


[Gd] App Engine team appearances Winter 2011

| More

Google App Engine Blog: App Engine team appearances Winter 2011

The Google App Engine team has launched some significant features recently, including: High Replication Datastore, Channel API, Always On, Warm Up requests, longer 10-minute (vs. 30-second) limit for tasks, and increased API call sizes. We are excited about these features and think you will be too, so team members will be appearing at a variety of events around the world this Winter to talk about some of these features and the platform as a whole!

One of the marquee events this quarter includes
PyCon, the largest gathering of Python developers from around the world, where several App Engine team members will be speaking:

Winter 2011 event appearances:

  • Jan 18 - ICT Meet Ethiopia 2011 - Addis Ababa - Richard Ngamita

  • Jan 22 - Google Hackathon (Year One Labs) - Montréal - Sean Lynch

  • Feb 1-3 - Strata - Santa Clara - Patrick Chanezon

  • Feb 14-16 - Jfokus - Stockholm - Patrick Chanezon

  • Feb 17-18 - Developer Summit - Tokyo - Takashi Matsuo

  • Feb 28-Mar 4 - Game Developers Conference - San Francisco - Fred Sauer

  • Mar 9-17 - PyCon - Atlanta - Guido van Rossum; Wesley Chun; Ikai Lan; Brett Slatkin

  • Mar 11-15 - SXSW - Austin - Sean Lynch; Greg D'alesandre

  • Mar 28-31 - Int'l WWW Conference - Hyderabad - Patrick Chanezon; Rajdeep Dua

If these aren't close enough to you, keep an eye out on this list as we'll add new events as they materialize. There is also a separate calendar for events featuring other Google products/APIs. For App Engine, look for posts like this throughout the year. We look forward to meeting you in 2011!

Posted by Wesley Chun, Google App Engine team

[Gd] [Libraries][Update] jQueryUI 1.8.8

| More

Google AJAX API Alerts: [Libraries][Update] jQueryUI 1.8.8

jQueryUI has been updated to 1.8.8

Wednesday, January 12, 2011

[Gd] AdWords Downtime: January 15, 10am-2pm PDT

| More

AdWords API Blog: AdWords Downtime: January 15, 10am-2pm PDT

We'll be performing routine system maintenance on Saturday, January 15 from approximately 10:00am to 2:00pm PST. You won't be able to access AdWords or the API during this time frame, but your ads will continue to run as normal.

- Eric Koleda, AdWords API Team

[Gd] Gingerbread NDK Awesomeness

| More

Android Developers Blog: Gingerbread NDK Awesomeness

[This post is by Chris Pruett, an outward-facing Androider who focuses on the world of games. —Tim Bray]

We released the first version of the Native Development Kit, a development toolchain for building shared libraries in C or C++ that can be used in conjunction with Android applications written in the Java programming language, way back in July of 2009. Since that initial release we’ve steadily improved support for native code; key features such as OpenGL ES support, debugging capabilities, multiple ABI support, and access to bitmaps in native code have arrived with each NDK revision. The result has been pretty awesome: we’ve seen huge growth in certain categories of performance-critical applications, particularly 3D games.

These types of applications are often impractical via Dalvik due to execution speed requirements or, more commonly, because they are based on engines already developed in C or C++. Early on we noted a strong relationship between the awesomeness of the NDK and the awesomeness of the applications that it made possible; at the limit of this function is obviously infinite awesomeness (see graph, right).

With the latest version of the NDK we intend to further increase the awesomeness of your applications, this time by a pretty big margin. With NDK r5, we’re introducing new APIs that will allow you to do more from native code. In fact, with these new tools, applications targeted at Gingerbread or later can be implemented entirely in C++; you can now build an entire Android application without writing a single line of Java.

Of course, access to the regular Android API still requires Dalvik, and the VM is still present in native applications, operating behind the scenes. Should you need to do more than the NDK interfaces provide, you can always invoke Dalvik methods via JNI. But if you prefer to work exclusively in C++, the NDK r5 will let you build a main loop like this:

void android_main(struct android_app* state) {
// Make sure glue isn't stripped.

// loop waiting for stuff to do.
while (1) {
// Read all pending events.
int ident;
int events;
struct android_poll_source* source;

// Read events and draw a frame of animation.
if ((ident = ALooper_pollAll(0, NULL, &events,
(void**)&source)) >= 0) {
// Process this event.
if (source != NULL) {
source->process(state, source);
// draw a frame of animation

(For a fully working example, see the native-activity sample in NDK/samples/native-activity and the NativeActivity documentation.)

In addition to fully native applications, the latest NDK lets you play sound from native code (via the OpenSL ES API, an open standard managed by Khronos, which also oversees OpenGL ES), handle common application events (life cycle, touch and key events, as well as sensors), control windows directly (including direct access to the window’s pixel buffer), manage EGL contexts, and read assets directly out of APK files. The latest NDK also comes with a prebuilt version of STLport, making it easier to bring STL-reliant applications to Android. Finally, r5 adds backwards-compatible support for RTTI, C++ exceptions, wchar_t, and includes improved debugging tools. Clearly, this release represents a large positive ∆awesome.

We worked hard to increase the utility of the NDK for this release because you guys, the developers who are actually out there making the awesome applications, told us you needed it. This release is specifically designed to help game developers continue to rock; with Gingerbread and the NDK r5, it should now be very easy to bring games written entirely in C and C++ to Android with minimal modification. We expect the APIs exposed by r5 to also benefit a wide range of media applications; access to a native sound buffer and the ability to write directly to window surfaces makes it much easier for applications implementing their own audio and video codecs to achieve maximum performance. In short, this release addresses many of the requests we’ve received over the last year since the first version of the NDK was announced.

We think this is pretty awesome and hope you do too.


[Gd] Chrome Stable Release

| More

Google Chrome Releases: Chrome Stable Release

Chrome on stable channel has been updated to 8.0.552.237 for all platforms.  Chrome OS has also been updated, to 8.0.552.334. These releases contain the security fixes listed below.

Security fixes and rewards:
Please see the Chromium security page for more detail. Note that the referenced bugs may be kept private until a majority of our users are up to date with the fix.

We’re delighted to offer our first “elite” $3133.7 Chromium Security Reward to Sergey Glazunov. Critical bugs are harder to come by in Chrome, but Sergey has done it. Sergey also collects a $1337 reward and several other rewards at the same time, so congratulations Sergey!

Also of note is a clarification on our default charity policy. Some researchers are unable to accept rewards, or even provide a suggestion for a charity. In such cases, it feels like a shame to lose a charitable contribution so we will default reward money to the Red Cross.
  • [58053] Medium Browser crash in extensions notification handling. Credit to Eric Roman of the Chromium development community.
  • [$1337] [65764] High Bad pointer handling in node iteration. Credit to Sergey Glazunov.
  • [66334] High Crashes when printing multi-page PDFs. Credit to Google Chrome Security Team (Chris Evans).
  • [$1000] [66560] High Stale pointer with CSS + canvas. Credit to Sergey Glazunov.
  • [$500] [66748] High Stale pointer with CSS + cursors. Credit to Jan Tošovský.
  • [67100] High Use after free in PDF page handling. Credit to Google Chrome Security Team (Chris Evans).
  • [$1000] [67208] High Stack corruption after PDF out-of-memory condition. Credit to Jared Allar of CERT.
  • [$1000] [67303] High Bad memory access with mismatched video frame sizes. Credit to Aki Helin of OUSPG; plus independent discovery by Google Chrome Security Team (SkyLined) and David Warren of CERT.
  • [$500] [67363] High Stale pointer with SVG use element. Credited anonymously; plus indepdent discovery by miaubiz.
  • [$1000] [67393] Medium Uninitialized pointer in the browser triggered by rogue extension. Credit to kuzzcc.
  • [$1000] [68115] High Vorbis decoder buffer overflows. Credit to David Warren of CERT.
  • [$1000] [68170] High Buffer overflow in PDF shading. Credit to Aki Helin of OUSPG.
  • [$1000] [68178] High Bad cast in anchor handling. Credit to Sergey Glazunov.
  • [$1000] [68181] High Bad cast in video handling. Credit to Sergey Glazunov.
  • [$1000] [68439] High Stale rendering node after DOM node removal. Credit to Martin Barbella; plus independent discovery by Google Chrome Security Team (SkyLined).
  • [$3133.7] [68666] Critical Stale pointer in speech handling. Credit to Sergey Glazunov.
Full details about the Chrome changes are available in the SVN revision log. If you find new issues, please let us know by filing a bug. Want to change to another Chrome release channel? Find out how.

Jason Kersey
Google Chrome

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 10.0.634.0 for Linux, Mac, Windows and Chrome Frame

This release fixes several crashes and small issues:

  • Updated V8 -
  • Chrome no longer says "restart required" when there's no update (Issue 67478)
Known Issues
  • Clear browsing data settings in DOMUI options does not work (Issue 69163)

More details about additional changes are available in the log of all revisions.

You can find out about getting on the Dev channel here:

If you find new issues, please let us know by filing a bug at

Karen Grunberg
Google Chrome

[Gd] Community Elections 2011: The Polls are open!!!

| More

OpenSocial API Blog: Community Elections 2011: The Polls are open!!!

The election for the OpenSocial Foundation's Community Board representative is now open. If you are a member, you should have received an email directing you to submit your ballot. The election will close at 11:59 PM PDT on Friday, January 21, 2011. You can find information on each person that has been nominated on the
candidate info page.

One of these candidates will be elected by the community to serve on the
OpenSocial Foundation's Board of Directors. As a reminder, the role of the OpenSocial Foundation is to promote the OpenSocial specification, and to help ensure that it remains freely implementable by all, in perpetuity. You can find more information about the foundation by visiting the OpenSocial Foundation FAQ.

If you have not submitted a membership application to the OpenSocial Foundation, and would like to have your voice heard in this election you still may do so. To be eligible to vote in the current election, you must complete the OpenSocial Foundation membership application (it's free) by 11:59 PM PDT on Sunday, January 16, 2011.

If you have any questions or comments about the election please visit the
OpenSocial community forum.

Posted by Mark Weitzel, President OpenSocial Foundation

Tuesday, January 11, 2011

[Gd] HTML Video Codec Support in Chrome

| More

Chromium Blog: HTML Video Codec Support in Chrome

The web’s open and community-driven development model is a key factor in its rapid evolution and ubiquitous adoption. The WebM Project was launched last year to bring an open, world-class video codec to the web. Since the launch, we’ve seen first-hand the benefits of an open development model:

  • Rapid performance improvements in the video encoder and decoder thanks to contributions from dozens of developers across the community
  • Broad adoption by browser, tools, and hardware vendors
  • Independent (yet compatible) implementations that not only bring additional choice for users, publishers, and developers but also foster healthy competition and innovation

We expect even more rapid innovation in the web media platform in the coming year and are focusing our investments in those technologies that are developed and licensed based on open web principles. To that end, we are changing Chrome’s HTML5 <video> support to make it consistent with the codecs already supported by the open Chromium project. Specifically, we are supporting the WebM (VP8) and Theora video codecs, and will consider adding support for other high-quality open codecs in the future. Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.

These changes will occur in the next couple months but we are announcing them now to give content publishers and developers using HTML <video> an opportunity to make any necessary changes to their sites.

Posted by Mike Jazayeri, Product Manager

[Gd] GWT Goes Bidirectional!

| More

Google Web Toolkit Blog: GWT Goes Bidirectional!

Over 100 million web users speak languages that are written right-to-left, such as Arabic, Hebrew and Persian.

Right-to-left language support is not new to GWT. GWT makes it easy to build applications localized to both right-to-left (RTL) and left-to-right (LTR) locales, mirroring the layout of the page and its widgets so that an RTL-language page flows right-to-left. GWT even makes it easy to mirror those "handed" images that need to point in a direction that makes sense within the page. So, what's the problem?

The Challenge of Bidi Text

An application localized to an RTL language is often used to access both RTL and LTR data, simply because data in some left-to-right languages like English is so widespread. For example, an Arabic movie review application may need to display Latin-script movie titles. Conversely, native RTL-language speakers often choose to use an English version of an application, but still use it to access and enter RTL data too. The point is that the data should be displayed in its own direction, regardless of the context’s direction. As a result, the text of the page as a whole goes in both directions; the page’s text is bidirectional, or “bidi”.

Unfortunately, inserting an opposite-direction phrase into your page without explicitly indicating where it begins and ends, often garbles it and/or the text surrounding it, putting the words and punctuation in the wrong order. For example, in an RTL context, “10 Main St.” is displayed incorrectly as “.Main St 10”. For short, we call the capability to display opposite-direction text correctly “bidi text support”.

The good news is that GWT has recently been enhanced with some powerful features for supporting bidi text. They allow your application to correctly display and enter opposite-direction text with very little extra effort.

Built-in Bidi Text Support in TextBox and TextArea

Since GWT 2.1 release, the TextBox and TextArea widgets are capable of automatically adjusting their direction as text is being entered (GWT Showcase example). This feature is enabled by default when at least one of the application's locales is RTL, and otherwise can be enabled manually.

Built-in Bidi Text Support in Other Widgets

As of GWT 2.2 (to be released soon), several widely used widgets such as Label, HTML, Anchor, Hyperlink and ListBox gain built-in bidi text support by exposing two new interfaces:

  • The HasDirectionalText interface allows declaring the direction of text whose direction is known in advance. For example, a Label holding a phone number is always LTR, even in RTL locales, and must be declared as such to prevent garbling. You can do this by passing an extra parameter to either the constructor:
    Label label = new Label(phone, Direction.LTR);
    or to setText():
    label.setText(phone, Direction.LTR);

  • The HasDirectionEstimator interface allows widgets to cope with text whose direction is unknown (for example text previously entered by users). When direction estimation is enabled, the widget estimates the direction of the text content at runtime, and sets its display direction accordingly. Note that usually there’s no need to use this feature for boilerplate text (i.e. messages), since such text usually matches the overall page direction.

In the following example, an imaginary application collects reviews of books from the users. A user can add to the repository a new book with its name and review. To view the review of a specific book, one can select its name from a ListBox holding the books’ names. Note that books’ names may be of both directions, especially in RTL locales.

public class BookReviewApp() {
private ListBox bookNamesListBox;

public BookReviewApp() {
// Enable bidi support.

public addBook(String bookName, String review) {
// ListBox item’s direction will be set automatically.



Bidi and Messages

BidiFormatter is a new class providing bidi text support primitives like estimating a string’s direction and wrapping it in HTML for correct display in a potentially opposite-direction context. The new built-in bidi text support features in the widgets mentioned above use BidiFormatter to do their stuff. Sometimes, however, you may need to use BidiFormatter directly. It is particularly useful with message placeholder values. While the message as a whole is usually localized to the user interface language, placeholder values may be in an arbitrary language and thus may have the opposite direction. Use BidiFormatter’s methods to wrap such values before inserting them into the message. A comprehensive example of using BidiFormatter with messages is available in the GWT Showcase.


[Gd] Beta Channel Update

| More

Google Chrome Releases: Beta Channel Update

The Beta channel has been updated to 9.0.597.47 for Windows.

Flash Player sandboxing has been restored for all platforms but XP as has accelerated composting and WebGL.

If you find new issues, please let us know by filing a bug at

Anthony Laforge
Google Chrome

[Gd] Drag and drop search for Go Daddy websites

| More

Google Custom Search: Drag and drop search for Go Daddy websites

Wouldn't it be nice to just drag and drop a Custom Search box onto a website?

We thought so, and so did Go Daddy, the world's largest domain name registrar and top web hosting provider. Website owners using Go Daddy's WebSite Tonight product can now easily drag a search widget onto their web pages, and instantly turn on high-quality website search powered by the Custom Search platform.

WebSite Tonight is a do-it-yourself service that lets users create, design, update and publish websites without requiring any knowledge of HTML. The product offers 1,500+ design templates and enables users to very easily add widgets to their web pages. WebSite Tonight was named for its ease of use - users can create a website as quickly as one night.

Here’s how you add Custom Search to your website in WebSite Tonight:

Step 1: Select "Google Custom Search" from the list of available widgets

Step 2: Select a predefined search theme to match the style of your website

Step 3: Drag and drop the Google Custom Search box to the desired location on your website

Step 4: Search! Google search results appear within the Go Daddy website

Go Daddy also integrates with Google Webmaster Tools as part of the Google Services for Websites program. As Go Daddy automatically submits Sitemaps to Google, changes to websites are quickly discovered and indexed by Google's crawlers, thereby improving search quality on both the individual website as well as

Ease of use plus better performance -- we like that combination. We hope you also like the concept of drag and drop search. As always, we'd love to hear your feedback.

Posted by: Radu Cornea, Software Engineer and Jae Jung, Senior Manager, New Business Development

Monday, January 10, 2011

[Gd] Google URL Shortener gets an API

| More

Google Code Blog: Google URL Shortener gets an API

When we launched Google’s URL shortener externally back in September, there was no accompanying API to allow people to integrate into their applications and web pages. However, we said that we were working on one, and today we're happy to announce that we’ve launched the API in Google Code Labs. The documentation can be found on the Google Code site, with example code in the Getting Started section.

With this API, developers are able to programmatically access all of the fast, sleek goodness that we currently provide via the web interface. You can shorten and expand URLs using the API, as well as fetch your history and analytics. You could use these features for a wide variety of applications, enabling behaviors ranging from auto-shortening within Twitter or Google Buzz clients to running regular jobs that monitor your usage statistics and traffic patterns. You can check out the Google APIs console to get started.

We’re very excited to be able to offer you this API to access one of the fastest URL shorteners out there. We’re continuing to work on several usability improvements and to make our auto-detection of spammy or malicious content even more robust. We hope that with the new API, you’ll find to be even more useful in your future shortening endeavors! If you’re an application developer, check out the API documentation and see how it looks.

By Ben D’Angelo, URL Shortener Team