Friday, July 2, 2010

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 6.0.453.1 for All platforms

  • Consolidated menu is on by default
  • [r50830] Show preview images when dragging images.
  • Printing from the built-in PDF plugin now prints vectors instead of pixels.
  • [r50617] Fix avutil-50.dll entry point not found error by limiting the DLL search path when loading FFmpeg binaries (Issue 35857)
  • Continued feature parity work
  • New experimental support for gnome-keyring and kwallet for storing your passwords.  Currently off by default; you can opt in via a command line flag and we’d love feedback as to whether it eats your data.  Please see this thread for information on how to test it (importantly, back up your passwords first).
  • Fixed overlapping characters sometimes seen with complex (Thai, Indic) text.
  • The PDF plugin is now available (turn it on in about:plugins).
More details about additional changes are available in the svn svn log of all revision.

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

Anthony Laforge
Google Chrome

[Gd] Stable Channel Update

| More

Google Chrome Releases: Stable Channel Update

Google Chrome 5.0.375.99 has been released to the Stable channel on Linux, Mac, and Windows.
This release fixes the following security issues:
  • [42396] Low OOB read with WebGL. Credit to Sergey Glazunov; Google Chrome Security Team (SkyLined).
  • [42575] [42980] Medium Isolate sandboxed iframes more strongly. Credit to sirdarckcat of Google Security Team.
  • [$500] [43488] High Memory corruption with invalid SVGs. Credit to Aki Hekin of OUSPG; wushi of team509.
  • [$500] [44424] High Memory corruption in bidi algorithm. Credit to wushi of team509.
  • [45164] Low Crash with invalid image. Credit to javg0x83.
  • [$1000] [45983] High Memory corruption with invalid PNG (libpng bug). Credit to Aki Helin of OUSPG.
  • [$500] [46360] High Memory corruption in CSS style rendering. Credit to wushi of team509.
  • [46575] Low Annoyance with print dialogs. Credit to Mats Ahlgren.
  • [47056] Low Crash with modal dialogs. Credit to Aki Helin of OUSPG.
 If you find issues, please let us know:

Jason Kersey
Google Chrome

[Gd] GWT 2.1 Milestone 2 is now available

| More

Google Web Toolkit Blog: GWT 2.1 Milestone 2 is now available

It’s been a busy week for the GWT team. We released an updated GWT Gadgets library, GWT 2.0.4, and to cap things off pushed the second milestone release of GWT 2.1 today. In this milestone we simplified the process of configuring a RequestFactory, made record creation within a RequestFactory more extensible, and properly moved ourselves out of bikeshed. A full list of features and fixes can be found here.

With the release of GWT 2.1 M2, we’re continuing to evolve the integration between Google and VMware that was announced at this year’s Google I/O. Each milestone release of GWT, Spring Roo, and STS fleshes out more of the envisioned feature set, and overall stability of the stack.

GWT 2.1 M2 is available on our Google Code download site. We’d love to hear your feedback and thoughts on this release, and our GWT Developer Forum would be the best place to post this information.


Thursday, July 1, 2010

[Gd] [Search][Release] Custom Search hides single tab

| More

Google AJAX API Alerts: [Search][Release] Custom Search hides single tab

If the Custom Search Engine has no refinements, no search tabs will be shown. (In this situation a single tab used to be shown.)

[Gd] [Search][Release] Custom Search Autocomplete

| More

Google AJAX API Alerts: [Search][Release] Custom Search Autocomplete

The Custom Search Control will now preserve preexisting onclick and onblur handlers which you have added to the search form's input box when attaching its own event handlers.

[Gd] Testivus, Testability and Dr. Jekill and Mr. Hide

| More

Google Testing Blog: Testivus, Testability and Dr. Jekill and Mr. Hide

by Alberto Savoia

A major topic at this year's GTAC conference is going to be testability: "We also want to highlight methodologies and tools that can be used to build testability into our products." That's great!

Testability is one of the most important, yet overlooked, attributes of code – and one that is not discussed enough. That's unfortunate, because by the time the issue of testability comes up in a project it's usually too late. As preparation and seeding for GTAC, I though it would be fun and useful to get some discussions on testability going. So here we go, feel free to chime in with your thoughts.

A few years ago, after watching one too many episodes of Kung Fu, I was inspired to write a pretentious and cryptic little booklet about testing called "The Way of Testivus" (PDF).

Testivus addresses the issue of testability in a few places, but I would like to start the discussion with this maxim:

To me, "Think of code and tests as one" is the very foundation of testability. If you don't think about testing as you design and implement your code, you are very likely to make choices that will impair testability when the time comes. This position seemed obvious and non-controversial to me at the time I wrote it, and I still stand by it. Most people seem to agree with it as well, and more than one person told me that it's their favorite and most applicable maxim from all of Testivus. There are however three groups of people who found issue with it.

Some of the people, mostly from the TDD camp, think that my choice of words leaves too much wiggle room: "Thinking about the tests is not enough, they should be writing and running those tests at the same time."

Others think that code and tests should not be thought of as one at all, but they should be treated independently – ideally as adversaries: "I don't want code and tests to be too "friendly". Production code should not be changed or compromised to make the testing easier, and tests should not trust the hooks put in the code to make it more testable." Most of the people in this camp are not big fans of unit/developer testing in the first place, but not all. One person, a believer in developer testing, told me that he gets the best results with a Dr. Jekill and Mr. Hide approach. He assumes two different roles and personalities based on whether he's coding or testing his own code. When coding, he's the constructive Dr. Jekill who focuses on elegant and efficient design and algorithms – and does not worry about testability. When testing, he turns into the destructive Mr. Hide; he tries to forget that it's his code or how he implemented it, and puts all his energy and anger into trying to break it. Sounds like it could work quite well – though I don't think I'd want this person as an office mate during the Mr. Hide phase.

A third group, thought that the maxim was fine for unit tests, but not applicable to other types of tests that were best served by an adversarial black-box approach.

What are your thoughts? Is it enough to think about testability when designing or writing the code, or must you actually write and run some tests in parallel with the code? Does anyone agree with the position that code and tests should be designed and developed in isolation? Are there other Dr. Jekills and Mr. Hides out there?



[Gd] Discover v2009: Working with AuthTokens

| More

AdWords API Blog: Discover v2009: Working with AuthTokens

Authorization tokens were introduced with v2009 as part of the authorization mechanism adopted for the new version, ClientLogin. This new approach allows us to separate authorization from API requests, making it a two step process: first retrieve a token, and then include it with your requests.

How ClientLogin works

ClientLogin was designed as a standalone authentication and authorization procedure that returns a token, if successful. This token is then supplied together with the requests as a form of proof that the user is who they claim to be, and that they are allowed access to the API. Since both the authorization and the requests happen over SSL connections, there is no risk of anyone retrieving the token and impersonating the user.

Explaining how to implement a full ClientLogin handler is outside the scope of this blog post, but for the full details on the protocol please consult the documentation. Here is a small example of how to log in using the AuthToken module included with the Ruby client library (which can be used outside of it, since its only dependency is the httpclient gem):

require 'authtoken'

auth_token = AdWords::AuthToken.get_token(email, password,

'', 443, true)

Other client library projects include NoClientLib pages in their wikis detailing how to perform the ClientLogin step (as well as all other steps in a successful request) without the client library.

If you’re using the client libraries, the ClientLogin step is usually handled for you, although you’ll still need to keep an eye out for any errors. The Readme file included with your client library has more details.

Remember to reuse the authorization tokens

This is a point of some confusion among developers, and illustrates one of the key differences in authorization between v13 and v2009: In v13, you authenticated and authorized every request by sending your account credentials as part of the header; in v2009, you authenticate with ClientLogin beforehand and then authorize your request to the AdWords API by supplying the token generated by ClientLogin.

A naive migration from v13 to v2009 would generate a new token for every request and insert it into the header. This is a bad idea. Such an implementation will very likely cause your software to run into CAPTCHAs and block your accounts until the CAPTCHAs are resolved.

A correct implementation would generate the token, cache it, and reuse it for all subsequent requests with that email address, even against the sandbox.

Handling expiration and errors

Tokens don’t last forever; as a security mechanism, they only last up to two weeks. Do bear in mind, though, that this doesn’t mean they’ll last a full two weeks: Authorization tokens can at any time be revoked for any number of reasons (usually for security). If a token has been revoked, you’ll get back an AuthenticationError with the reason GOOGLE_ACCOUNT_COOKIE_INVALID.

Most of these errors can be handled simply by requesting a new authorization token, but if you get back a CaptchaRequired error when performing the ClientLogin interactions, you’ll need the user to resolve the CAPTCHA before you’re allowed generation of new tokens (or wait approximately 5 minutes, after which it will work again). The error message will include a URL to the image and a CAPTCHA token, so you can embed this directly into your application, without having to redirect the user to a web page. Check the ClientLogin documentation for details.

What to keep in mind when implementing your application

When implementing your application, keep these best practices in mind:
  • Generate a new token before the first request your application makes. You’ll need a token for every different email header that you use, so:
    • if you log in by setting the email header to your MCC (My Client Center) account and then change the clientEmail header to the different accounts you’re accessing, you’ll only need a single token;
    • if you log in by setting the email and password headers directly to those of the different accounts you’re accessing, you’ll need a new token for each.
  • Reuse this token in subsequent requests.
  • If you receive an AuthenticationError back, take a look at the reason:
    • if it indicates an expired token, try generating a new one and proceeding;
    • if it indicates an unrecoverable error, present the information to the user, and let them decide how to proceed.

Finally, if you’re using one of our client libraries, then we have good news for you: the first two steps are already taken care of! Just set your credentials according to the instructions for your specific client library, and it will manage both v13 and v2009 authorization for you.

Keep in mind that if you have any further questions or run into any other authorization issues, the documentation and the forum are the right place to go!

--Sérgio Gomes, AdWords API Team


[Gd] The Broad Match Modifier and the API

| More

AdWords API Blog: The Broad Match Modifier and the API

Back in May, we announced the new “broad match modifier” in AdWords, which lets you create keywords with more reach than phrase match and more control than broad match. For now, this feature is only available in the UK and Canada, but it will be rolled out to more countries this summer.

We’ve heard developers asking when this will be supported in the API, so we want to let you know that it already is. To use the broad match modifier, simply add plus signs (+) to your keyword text as desired. Because these keywords are still considered BROAD match, no additions to the KeywordMatchType enum are necessary.

Unless you prohibit the entry of the plus symbol (+) character in keyword text fields or reports, you may not need to change your code at all. However, we recommend testing to make sure.

For more information on the broad match modifier, visit the AdWords Help Center. And as always, you can post any questions you have regarding the API to the forum.

-Aaron Karp, AdWords API Team

[Gd] GWT 2.0.4 is now available

| More

Google Web Toolkit Blog: GWT 2.0.4 is now available

Recently Apple released Safari 5, which included a bug where non-integral right-shifts were not being evaluated properly. There were several reports, both internally and externally, of GWT-based applications unexpectedly crashing when running in Safari 5 (including Google Wave). Upon further inspection of the crash, we determined that the bug is triggered when calling several of GWT's array sorting methods, which in turn perform non-integral right-shifts as part of the compiled code.

That's the bad news. The good news is that we have a fix for this issue, plus several other house keeping items that we've rolled into a 2.0.4 release, which can be downloaded from GWT’s main download site.

If you’re experiencing the Safari crash, you’ll need to recompile and deploy your GWT app. The changes in 2.0.4 are completely compatible with your existing 2.0 app, and should have no negative impact. To that extent we’ve already dogfooded 2.0.4, verifying that it fixes the Wave crash that was originally reported.


Wednesday, June 30, 2010

[Gd] Making Chrome more accessible with extensions

| More

Chromium Blog: Making Chrome more accessible with extensions

Personalizing the web to match the needs and abilities of users is a big part of improving overall web accessibility. While we continue to work hard on making core Google Chrome more accessible, we're really excited about using browser extensions to improve the accessibility of the web for millions of users.

There are already some extensions among the more than 5,000 in the gallery that can benefit users with special needs. Some of these extensions use Chrome APIs and content scripts to alter the browser and manipulate the DOM of pages, offering users almost unlimited flexibility for viewing the web. Other extensions choose to implement altenative workflows, instead of adapting existing web page UIs, to give users faster access to content. These extensions benefit not just users of assistive technologies like screen readers but everyone who prefers access modes like keyboard shortcuts and captions.

If you are interested in making your extensions more accessible, we’ve created a new Accessibility implementation guide in the Chrome Extensions Developer's Guide that gives you an overview of accessibility best practices such as keyboard navigation, color contrast and text magnification. We’ve also open sourced the code behind ChromeVis, a new extension for users with low vision, so that you can use some of its code for manipulating text selection and magnification in your own extensions.

Already the NPR team has implemented some accessibility best practices in their extension. We hope to see more extensions adopting them. From our end, we're sponsoring a Summer of Code project to produce an extension that helps users produce custom style sheets and plan to create additional extensions that make navigating the web through Chrome easier.

We've also set up a Google Moderator topic where everyone can submit ideas for extensions that improve web accessibility. We hope these ideas will inspire extensions developers who are looking to create something useful for the community.

Stay tuned for future updates about Chrome Extensions and accessibility!

Posted by Rachel Shearer, Software Engineer

[Gd] App Engine SDK 1.3.5 Released With New Task Queue, Python Precompilation, and Blob Features

| More

Google App Engine Blog: App Engine SDK 1.3.5 Released With New Task Queue, Python Precompilation, and Blob Features

Today we are happy to announce the 1.3.5 release of the App Engine SDK for both Python and Java developers.

Due to popular demand, we have increased the throughput of the Task Queue API, from 50 reqs/sec per app to 50 reqs/sec per queue. You can also now specify the amount of storage available to the taskqueue in your app, for those with very large queues with many millions of tasks. Stay tuned for even more Task Queue scalability improvements in the future.

Additionally, in this release we’ve also added support for precompilation of Python source files to match the same feature we launched for Java last year. For Python, you can now use precompilation to speed up application loading time and to reduce CPU usage for new app instances. You can enable precompilation by including the following lines in your app.yaml file:


- python_precompiled

This will start offline precompilation of Python modules used by your app when you deploy your application. Currently precompliation is off by default for Python applications, but it will be enabled by default in some future release. (Java precompilation has been enabled by default since the release of 1.3.1.)

To give you a taste of what this feature is like, we tested this on a modified version of Rietveld (which included a copy of Django 1.0.4 in the app directory, and which did not use the datastore in its base url). The latency and CPU usage results for the initial load of the application, after uploading a new version of the app and requesting the homepage, were:

Before precompilation enabled:

Test 1: 1450ms 1757cpu_ms

Test 2: 1298ms 1523cpu_ms

Test 3: 1539ms 1841cpu_ms

After precompilation enabled:

Test 1: 805ms 669cpu_ms

Test 2: 861ms 702cpu_ms

Test 3: 921ms 803cpu_ms

Of course, any individual app’s performance will vary, so we recommend that you experiment with the setting for your application. Please submit your feedback and results to the support group!

In addition to Task Queues and Python precompilation, we have made a few changes to the Blobstore in 1.3.5 First, we have added file-like interfaces for reading Blobs. In Python, this is supported through the BlobReader class. In Java, we have implemented the BlobstoreInputStream class, which gives an InputStream view of the blobs stored in Blobstore.

More information on this release can be found by reading the release notes for Python and Java.

Posted by the App Engine Team

[Gd] PayPal introduces PayPal X Platform Toolkit for Google App Engine

| More

Google App Engine Blog: PayPal introduces PayPal X Platform Toolkit for Google App Engine

Hello App Engine Developers!

My name is Praveen Alavilli (@ppalavilli) and I work as a developer evangelist for PayPal's X Platform at I want to take the opportunity to introduce you to our new open source toolkit for Google App Engine that provides an easy way to integrate your Java apps running on App Engine with the new PayPal's Adaptive Payments API. Currently this is a Java toolkit explicitly for App Engine Java, but a Python version will be coming out soon.


The Adaptive Payments API provides a set of core services offered by the PayPal X Open Global Payments Platform to enable developers to embed payments into their applications, services, and platforms. The Adaptive Payments APIs offer several new payments functionality like Split Payments and Preapprovals, that enable developers to implement a variety of monetization models - freemium, subscriptions, pay-per-use, value-added-services, micro-transactions, e-commerce, etc. in their applications built and running on the App Engine. Whether you are building an application for Businesses to process back-end disbursements or payouts to affiliates, or building a social or gaming app for Facebook / Twitter / Open Social, or building a Desktop gadget for premium content, or building a Geolocation app that only helps users find places and people around where they are but even help in transacting them, or building a Web2.0 AJAX app that mashes up content and services, or several more use cases enabled by App Engine, now you can use the PayPal X toolkit to enable payments in them as it fits the needs.

Using the toolkit

Getting started with App Engine toolkit is easy. You can either checkout the source code from svn and import it into your Eclipse project or simply download the prebuilt jar file and include it in your application's class path (/WEB-INF/lib). Similar to other APIs that you might have used, you would need PayPal API Credentials to authenticate your API requests. With the toolkit you simply create an "APICredential" object from one of your application initialization methods (in most cases from your Servlet init() method) and load the API Credentials that you have obtained from the PayPal Sandbox. (Please refer to PayPal's Sandbox guide for more detailed information on how to obtain them).

// Obtain the credentials from your configs
credentialObj = new APICredential();

// setup your AppID from

// setup your Test Business account email
// in most cases this would be associated with API Credentials

// add required error condition checks

Once the APICredentialObj is initialized successfully, save it in the application's local context so you do not need to reinitialize it on every request.

At its core, the Adaptive Payments API provides 5 generic API methods: Pay, Pay Details, Preapproval, Preapproval Details, Cancel Preapproval, Refunds, and Convert Currency. The toolkit provides the base API Request classes required to make those API calls. To make it even simpler, the toolkit also provides a few functional API wrapper classes that not only abstracts the APIs in terms of the functionality exposed (SimplePay, ChainedPay, ParallelPay, CreateSimplePreapproval, CreatePreapprovalForPeriodicPayments, PreapprovedChainedPay, etc.) but also provides a few exceptions that helps in handling errors more easily than the generic API Responses.

A Simple example

To give you an example, let's say you are building a SaaS model application on App Engine that you charge your customers based on their usage. While on-boarding customers to use your app, you can use the Preapproval API to obtain authorization from your customers to charge them for the app/service based on their usage in the future. In this case you can simply use the 'CreateSimplePreapproval' to create and send a request as below:

try {

// CreateSimplePreapproval request to setup a simple
// preapproval with no Payment Period Set
CreateSimplePreapproval simplePreapproval =
new CreateSimplePreapproval();

// set the API Credentials object (as given in the code above)

// starting date in yyyy-MM-dd format

// ending date in yyyy-MM-dd format
// in this case it's for an year from the starting date

// set max total amount of all Payments

// set max amount for each payment - let's say $1

// set max number of payments allowed - (52 weeks)

// set where to send the user in case of a cancellation
simplePreapproval.setCancelUrl(req.getRequestURL() +

// set where to return the user after successful approval
simplePreapproval.setReturnUrl(req.getRequestURL() + "?

/* Set other required fields */
// ... //

// set memo for user's transaction history
simplePreapproval.setMemo("Preapproval for GAE Sample");

// send the request
PreapprovalResponse preapprovalResponse =

} catch (//...exceptions go here...//) {
// handle exceptions as necessary


In this case, when the 'AuthorizationRequiredException' is thrown, your application would need to redirect the user to PayPal for authorizing the preapproval. The 'getAuthorizationUrl' method takes care of building the PayPal authorization url along with the Preapproval Key returned by the Preapproval API. Once the user authenticates and authorizes the preapproval request on, the user will be redirected back to your 'returnUrl' along with the preapprovalKey, which your application can verify by using the 'PreapprovalDetailsRequest' and store it in it's own app engine data store securely. From that point onwards, whenever the user needs to be charged for their usage of the application, the application can use one of the 'PreapprovedSimplePay' or 'PreapprovedParallelPay' or 'PreapprovedChainedPay' classes to make a payment on behalf of the user. Please refer to the sample apps to understand how to use the other classes provided by the toolkit to make Parallel,Chained or Simple Payments. For eg. the in the PicMart sample app shows how you can make a parallel payment to two receivers at the same time.

Further examples

As mentioned earlier, if you are building a social game where users can buy digital goods (eg. micro-payments) and virtual currencies while playing a game, you can use the same Preapproval API to obtain authorization from them so you could charge their PayPal accounts as and when needed, without requiring them to re-enter their payment information or redirect to PayPal for authorizing the payments.

Other examples of using the toolkit can include:

  • An application that lets merchants or enterprises pay their suppliers, or manage affiliate networks

  • Applications to enable property owners to collect rental payments from tenants

  • With a mult-merchant marketplace, a simple payroll app enables employee salary payments in multiple countries

  • ...

As you can see, the toolkit's support of the Adaptive Payments APIs can easily enable all of these usecases.

Where to find more info

Please look at the sample code provided in the samples directory. The class in AdaptiveSample and AdaptiveSampleFnAPI shows how to use the helper classes to send and receive requests. The PicMart sample app provides a simple example of how the Parallel Payment can be used in a Photo Printing app that let's users to buy prints of the pictures from Picasa Album of the photographer. This sample app uses the Picasa APIs to fetch the album and picture information from Picasa.

To learn more about the PayPal X Toolkit for App Engine, please visit: and to learn more about Adaptive Payments, please visit: You can find a lot of resources for developers like documentation, technical spec, sample apps, code, sdks, technical forums, technical support, etc.. on PayPal X Developer Network web site (

Posted by Praveen Alavilli (@ppalavilli), PayPal X Developer Network.