Saturday, October 29, 2011

[Gd] Downloading reports for lots of client accounts

| More

AdWords API Blog: Downloading reports for lots of client accounts

Reporting has changed significantly with v201109. We’d like to take this opportunity to discuss how to download reports for lots of clients simultaneously. To download reports for a large number of client accounts, we recommend requesting the download of these reports simultaneously.

We recommend requesting no more than 10 reports concurrently and to use one thread for each concurrent download. If for some reason the report download fails, we recommend you retry after a short wait. The length of the wait should increase with the number of times the request has been tried (known as Exponential Backoff). This backoff algorithm helps prevent making too many requests to the server in a short period of time.

You should check the specific reason the download failed and only retry if it was a transient error (such as exceeding the rate limit) instead of retrying if the report definition XML was invalid. The HTTP Status of the response provides useful information:
  • HTTP Status 500 indicates there is a transient server side issue and the request can be retried after a delay. We retrying no more than 5 times for any given report.
  • HTTP Status 400 indicates there was a problem with the request (or the report itself) and retrying will not help.
  • HTTP Status 200 means the report download was successful.
With v201109 you should use Ad Hoc reports to download new reports. With this new feature, there is no need for stored ReportDefinitions. The XML describing a Report Definition is sent directly with report download. A developer token is required, but the API call accrues no costs (report downloads are now free!).

Another benefit of downloading reports in this fashion is you get data more quickly than with legacy cross-client reports. As soon as a report download succeeds, you can start processing the data by putting it into a database or performing further logic on the results.

We hope this discussion of best practices will help you with writing report download code in the future. We’ve published a reference implementation showing how to do this in java here. If you have any questions about downloading reports, you can ask us on the forum.

, AdWords API Team

[Gd] Cleaning up the root collection in Google Docs

| More

Google Apps Developer Blog: Cleaning up the root collection in Google Docs

We are currently rolling out a change to the organization of existing resources in collections in Google Docs. This change is completely transparent to users of the Google Docs web user interface, but it is technically visible when using the Google Documents List API to make requests with the showroot=true query parameter or specifically querying the contents of the root collection. In order to understand this change, first read how Google Docs organizes resources.

The change involves Google removing those resources from a user’s root collection that already exist within another collection accessible to the given user. That is, if “My Presentation” is currently in root and in the “My Talks” collection, after this change it will only exist in the “My Talks” collection.

We are making this change in order to make the organization of resources less confusing for API developers. This change allows clients to know that a resource either exists in root or in some collection under root. Clients can still retrieve all resources, regardless of which collections they’re in, using the resources feed.

The change is rolling out gradually to all Google Docs users over the next few months.

Developers with further questions about this change should post in the Google Documents List API forum.

Russ Jorgensen LinkedIn

Russ Jorgensen joined Google in 2010 and is responsible for supporting and enhancing APIs which third-party applications can use to access and manage users' collections of Google Docs. Prior to working at Google, Russ was an embedded software engineer for 22 years at Bell Labs building telecommunications products such as PBXs and wireless communication systems.


[Gd] 4 ways to do Mail Merge using Google Apps Script

| More

Google Apps Developer Blog: 4 ways to do Mail Merge using Google Apps Script

Editor’s Note: This blog post is co-authored by James, Steve and Romain who are Google Apps Script top contributors. -- Ryan Boyd

The Google Apps Script team is on a roll and has implemented a ton of new features in the last few months. Some of us “Top Contributors” thought it will be a useful exercise to revisit the Mail Merge use case and discuss various ways in which we can do Mail Merge using Apps Script. Below are several techniques that tap into the power of Google Apps Script by utilizing Gmail, Documents and Sites to give your mailings some zing. Mail Merge is easy and here is how it can be done.

1. Simple Mail Merge using a Spreadsheet

The Simple Mail Merge tutorial shows an easy way to collect information from people in a Spreadsheet using Google Forms then generate and distribute personalized emails. In this tutorial we learn about using “keys,” like ${"First Name"}, in a template text document that is replaced by values from the spreadsheet. This Mail Merge uses HTML saved in the “template” cell of the spreadsheet as the content source.

2. Mail Merge using Gmail and Spreadsheet Services

The Gmail Service is now available in Google Apps Script, allowing you to create your template in Gmail where it is saved as a draft. This gives us the advantage of making Mail Merge more friendly to the typical user who may not know or care much about learning to write HTML for their template. The mail merge script will replace the draft and template keys with names and other information from the spreadsheet and automatically send the email.

To use this mail merge, create a new spreadsheet, and click on Tools > Script Gallery. Search for “Yet another Mail Merge” and you will be able to locate the script. Then, click Install. You’ll get two authorization dialogs, click OK through them. Add your contact list to the spreadsheet, with a header for each column. Then compose a new mail in Gmail. Follow this syntax for the “keys” in your template: $%column header% (see above). Click Save now to save your draft. Go back to your spreadsheet and click on the menu Mail Merge. A dialog pops up. Select your draft to start sending your emails.

You can add CCs, include attachments and format your text just as you would any email. People enjoy “Inserting” images in the body of their emails, so we made sure to keep this feature in our updated mail merge. To automate this process we will use a new advanced parameter of the method sendEmail, inlineImages. When the script runs it looks in the email template for images and make sure they appear as inline images and not as attachments. Now your emails will look just as you intended and the whole process of mail merge got a whole lot simpler.

3. Mail Merge using Document Forms

The next Mail Merge will use a template that is written in a Google Document and sent as an attachment. Monthly reports, vacation requests and other business forms can use this technique. Even very complex documents like a newsletter or brochure can utilize the automation of Google Apps Script to add the personal touch of having your patron’s name appear as a salutation.

Like in the Mail Merge for Gmail, the Google Docs template will use “keys” as placeholders for names, addresses or any other information that needs to be merged. Google Apps Script can add dynamic elements as well. For example you may want to include a current stock quote using the Financial Service, a chart from the Charts Service, or a meeting agenda automatically fetched for you by the Calendar Service.

As the code sample below demonstrates, the Google Apps Script gets the document template, copies it in a new temporary document, opens the temp document, replaces the key placeholders with the form values, converts it to PDF format, composes the email, sends the email with the attached PDF and deletes the temp document.

Here is a code snippet example to get you started. To use this mail merge, create a new spreadsheet, and click on Tools > Script Gallery. Search for “Employee of the Week Award” and you will be able to locate the script.

// Global variables 
docTemplate = “enter document ID here”;
docName = “enter document name here”;

function sendDocument() {
// Full name and email address values come from the spreadsheet form
var full_name = from-spreadsheet-form
var email_address = from-spreadsheet-form
// Get document template, copy it as a new temp doc, and save the Doc’s id
var copyId = DocsList.getFileById(docTemplate)
.makeCopy(docName+' for '+full_name)
var copyDoc = DocumentApp.openById(copyId);
var copyBody = copyDoc.getActiveSection();
// Replace place holder keys,
copyBody.replaceText('keyFullName', full_name);
var todaysDate = Utilities.formatDate(new Date(), "GMT", "MM/dd/yyyy");
copyBody.replaceText('keyTodaysDate', todaysDate);
// Save and close the temporary document
// Convert temporary document to PDF by using the getAs blob conversion
var pdf = DocsList.getFileById(copyId).getAs("application/pdf");
// Attach PDF and send the email
MailApp.sendEmail(email_address, subject, body, {htmlBody: body, attachments: pdf});
// Delete temp file

4. Mail Merge using Sites and Spreadsheet Services

For the last example let’s assume you have a great Google Site where you create new letters for your followers. However, you have had some feedback suggest that while many users don’t mind visiting your site, some would prefer to have the newsletter emailed to them. Normally this would require copying and pasting into an email or doc. Why not simply automate this with Google Apps Script?

The body section of a site, the part you edit, can be captured as HTML by the Sites Service and placed in the body of an email. Because the return value is HTML, the pictures and text formatting come through in the email.

Here is a simple example for you to try out:

function emailSiteBody() {  
var site = SitesApp.getPageByUrl('YourPageURL');
var body = site.getHtmlContent();

MailApp.sendEmail('', 'Site Template', 'no html :( ', {htmlBody: body});

It really is that simple. Add a for loop with email values from a spreadsheet and this project is done.

Happy merging!

Updated 10/28: fixed instructions for accessing the complete script source for solution 3.

James Ferreira   profile

Author, Scripter, and developer of free apps for non-profits and schools, James has written software to help more than half a million people by extending Google Apps.

Steve Webster   profile

Google Sites and Scripts expert from Dito specializing in training and application development. When not busy finding solutions to enhance customer capability in Google Apps, Steve shares examples of his work in the Google Apps Developer Blog.

Romain Vialard   profile | YouTube

Google Apps Change Management consultant at Revevol, Romain writes scripts to automate everyday tasks, add functionality and facilitate rapid adoption of cutting edge web infrastructures.


Friday, October 28, 2011

[Gd] Beta Channel Update for Chromebooks

| More

Chrome Releases: Beta Channel Update for Chromebooks

The Beta Channel has been updated to 15.0.874.116 (Platform version: 1011.107) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48)

Release highlights:
  • A number of functionality and stability fixes
  • Flash updated to
  • Web UI login connectivity and authentication fixes
  • 3G Activation fixes
Known issues:
  • Two finger scroll may brake after AU (Issue: 20511) - Work around: Power cycle device
  • When logging out from Guest with Accessibility on, the system hangs (Issue: 22133)

If you find new issues, please let us know by visiting our help site or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue’ under the wrench menu.

Josafat Garcia
Google Chrome

[Gd] Upcoming YouTube API Events

| More

YouTube API Blog: Upcoming YouTube API Events

It was a pleasure meeting YouTube developers at the recent GDD, DevFest and GTUG sessions in São Paulo, Buenos Aires, Moscow, Prague, Paris and Warsaw. We would like to let you know that our around-the-world API tour continues and we hope to meet you at one of our upcoming YouTube API presentations. Here is the list of currently planned YouTube sessions:
We will also be speaking at local GTUGs; for the most up to date information please check the event schedule of a GTUG near you. As always, upcoming event information can be found on our Google Developer Events Calendar available at

--Jarek Wilkiewicz, YouTube API Team

Thursday, October 27, 2011

[Gd] Dev Channel Update

| More

Chrome Releases: Dev Channel Update

The Dev channel has been updated to 16.0.912.15 for Windows, Mac, Linux, and Chrome Frame. This release contains fixes for stability. Full details about what changes are in this build are available in the SVN revision log.  Interested in switching to the Beta or Stable channels?  Find out how.  If you find a new issue, please let us know by filing a bug.

Dharani Govindan
Google Chrome

[Gd] ProdEagle - Analyzing your App Engine apps in real-time

| More

Google App Engine Blog: ProdEagle - Analyzing your App Engine apps in real-time

Today’s post comes to us from Andrin von Rechenberg of MiuMeet who has developed an easy to use analysis framework, ProdEagle, for App Engine apps. ProdEagle enables you to easily count and visualize events to help better understand both performance and usage of your site.

ProdEagle allows you to monitor your system, lets you analyse in real-time what is going on and can alert you if something goes wrong.

The story

We are a small start-up that created an incredibly fast growing social dating platform called MiuMeet. We used App Engine from the start and within 6 months we had over 1 million registered users - the system scaled beautifully. One of the world’s leading online dating companies invested in our start-up and gave us a very good piece of advice: Before you build new features, you need to understand what’s actually going on in your system. Of course we thought we knew exactly what is going on in our system. We had the App Engine Dashboard and we had Google Analytics and we ran a couple of daily MapReduces to collect some statistics. But honestly, compared to today, we didn’t have any idea what was going on.

Understanding your system

From our MapReduces we knew that most users who accessed our dating platform used our Android app and only very few users used our iPhone app. We weren’t exactly sure what the reason for that was, but we wanted to improve the experience for our iPhone users. So we had to start measuring what was different for iPhone vs Android users.

But how do you do this? You start recording everything that happens in your system. And by “everything” we don’t mean the status code of an HTTP response but human understandable events, like “an Android user starts a conversation”, “the average length of a conversation”, “how often iPhone users log in” and so on. We realized that iPhone users are much less active and reply less often - not because they don’t want to, but because they don’t know immediately that they got a new message. Android users are informed by Push-Notifications, iPhone users via email. We did not expect that this would make such a big difference, but now it’s pretty obvious what the next feature we should build to improve the iPhone experience. Our conclusions are based on hard numbers and not guesses.

We used ProdEagle to collect and analyse the data that allowed us to realize this. ProdEagle can count, display and compare events in real-time and can even alert you if something is going wrong.

How to measure events

Let’s start with a simple Python example. We would like to record the devices from which messages are sent in our system. All we have to do is add the green lines to our sendMessage function:

import prodeagle

def sendMessage(from, to, text, device):

 mailbox = getMailbox(to)

 mailbox.addMessage(from, text)

 prodeagle.counter.incr("Message." + device)

This one line of code and a few clicks in the ProdEagle dashboard allows us to create the following graphs:

    *The numbers in these graphs are just examples.

Analysing your system in “real-time”

With ProdEagle you can count whatever you want. The advantage over traditional analytics systems is that you don’t have to wait for a day for the data to appear. Data appears within 1 minute in your dashboard. This means that you can monitor your system almost in real-time and set up alerts if something goes wrong.

In the following example we measure how long it takes to execute a datastore query:

def searchPeople(query):

 timestamp = time.time()




                        time.time() - timestamp)

In the ProdEagle Dashboard we can specify that “Search.People.Latency” should  be divided by “Search.People.Count” and plot it as a graph. Additionally we can set up an email alert that fires if the latency was more than 4000ms for 5 minutes:

If the latency is above all the red dots you get an email alert.

Being able to measure latency in real-time is particularly useful when you are trying to optimize your system and want to try out different strategies to answer queries.

The magic behind ProdEagle

Whenever you call prodeagle.counter.incr(counter_name)the ProdEagle library increments a counter in memcache -  this shouldn’t add any noticeable latency to your app, unless it is the first call made by a serving instance. Every few minutes, the ProdEagle service that we run collects all these memcache counters and persists them, creates the graphs and alerts you if something is wrong.

Obviously, the system isn’t robust if your memcache gets flushed. To address this, ProdEagle uses 1024 dummy counters to check when your memcache gets flushed and to approximate the inaccuracy of the data in your graphs. This is based on the assumption that elements with the same size in memcache are freed in a “least-recently-used” fashion and that the 1024 dummy counters hit all memcache shards. We have used ProdEagle for MiuMeet for a couple of months now and our approximated accuracy was never below 99.8%.

I like! How can I get it?

ProdEagle is currently completely free of charge. You can download the python client libraries and sign up for your dashboard on

[Gd] On the road again - upcoming events around the world

| More

Google Apps Developer Blog: On the road again - upcoming events around the world

We’ve been busy traveling and meeting enthusiastic developers from around the world at our Google Developer Day and DevFest events. Early this month Ryan Boyd and Nicolas Garnier were off to Moscow, Prague, and Paris (with a side trip to a Warsaw GTUG). Before that, Saurabh Gupta and I were in Buenos Aires and Sao Paulo while Claudio Cherubino and Michael Manoochehri headed to Hyderabad and Bangalore.

Up next, I’ll be at our events in Tokyo, Sydney, Singapore, and Jakarta. Ryan Boyd and Michael Manoochehri will also be in Tel Aviv and Berlin. If you’re building integrations with Google Apps into your products to connect users with their data, helping customers integrate Google Apps with other parts of their Enterprise IT systems, or are simply customizing your own Google Apps environment, let’s meet!

Here’s my schedule:
For Ryan and Michael:
For those a little closer to our home in the San Francisco Bay Area, there are two other events here that are noteworthy. Neither is a Google sponsored event, but you’ll find several members of the Google Apps team in attendance.
  • First up is the gSocial conference on November 8-9 in Santa Clara, California. This is a peer-to-peer conference for Google Apps Resellers and Independent Software Vendors (ISVs) to collaborate, share best practices, and partner to grow their businesses.
  • The Small Business Web is hosting its first Summit on November 11-12 in San Jose, California. Software vendors, resellers, and distributors serving small businesses are attending to make decisions to push the industry forward over the next few months.
If you’re coming to any events of just happen to be near by, drop us a note on Google+ or twitter and we’d be happy to meet and talk with you.

Steven Bazyl   profile | twitter | events

Steve is a Developer Advocate for Google Apps and the Google Apps Marketplace. He enjoys helping developers find ways to integrate their apps and bring added value to users.


[Gd] ScriptCover makes Javascript coverage analysis easy

| More

Google Testing Blog: ScriptCover makes Javascript coverage analysis easy

By Ekaterina Kamenskaya, Software Engineer in Test, YouTube

Today we introduce the Javascript coverage analysis tool, ScriptCover. It is a Chrome extension that provides line-by-line Javascript code coverage statistics for web pages in real time without any user modifications required. The results are collected both when the page loads and as users interact with it. The tool reports details about total web page coverage and for each external/internal script, as well as annotated code sources with individually highlighted executed lines.

Short report in Chrome extension’s popup, detailing both overall scores and per-script coverage.

Main features:
  • Report current and previous total Javascript coverage percentages and total number of instrumented code instructions.
  • Report Javascript coverage per individual instruction for each internal and external script.
  • Display detailed reports with annotated Javascript source code.
  • Recalculate coverage statistics while loading the page and on user actions.

Sample of annotated source code from detailed report. First two columns are line number and number of times each instruction has been executed.

Here are the benefits of ScriptCover over other existing tools:
  • Per instructions coverage for external and internal scripts: The tool formats original external and internal Javascript code from ‘<script>’ tags to ideally place one instruction per line and then calculates and displays Javascript coverage statistics. It is useful even when the code is compressed to one line.

  • Dynamic: Users can get updated Javascript coverage statistics while the web page is loading and while interacting with the page.

  • Easy to use: Users with different levels of expertise can install and use the tool to analyse coverage. Additionally, there is no need to write tests, modify the web application’s code, save the inspected web page locally, manually change proxy settings, etc. When the extension is activated in a Chrome browser, users just navigate through web pages and get coverage statistics on the fly.

  • It’s free and open source!
Want to try it out? Install ScriptCover and let us know what you think.

We envision many potential features and improvements for ScriptCover. If you are passionate about code coverage, read our documentation and participate in discussion group. Your contributions to the project’s design, code base and feature requests are welcome!

[Gd] Introducing Android WebDriver

| More

Android Developers Blog: Introducing Android WebDriver

[This post is by Dounia Berrada, an engineer on the EngTools team. — Tim Bray]

Selenium WebDriver is a browser automation tool which provides a lightweight and elegant way for testing web apps. Selenium WebDriver is now available as an SDK extra in the Android SDK, and supports 2.3 (Gingerbread) and onwards!

Whether or not your site is optimized for mobile browsers, you can be sure that users will be accessing it from their phones and tablets. WebDriver makes it easy to write automated tests that ensure your site works correctly when viewed from the Android browser. We’ll walk you through some basics about WebDriver and look at it in action.

WebDriver Basics

WebDriver tests are end-to-end tests that exercise the web application just like a real user would. WebDriver models user interactions with a web page such as finger flicks, finger scrolls and long presses. It can rotate the display and interact with HTML5 features such as local storage, session storage and the application cache. Those tests run as part of an Android tests project and are based on Junit. They can be launched from Eclipse or the command line. WebDriver tests can be wired with a continuous integration system and can run on phone and tablet emulators or real devices. Once the test starts, WebDriver opens a WebView configured like the Android browser and runs the tests against it.

WebDriver is an Android SDK extra and can be installed following these instructions. Once you’ve done that you’ll be ready to write tests! There is a comprehensive WebDriver user guide on the Selenium site, but let’s start with a basic example using to give you a taste of what’s possible.

Getting Started

First, create an Android project containing an empty activity with no layout.

public class SimpleAppActivity extends Activity {
public void onCreate(Bundle savedInstanceState) {

Then create the Android test project that will contain the tests. WebDriver will create the WebView and set the layout automatically in the main Activity.

Let’s write a test that opens the Google home page on Android and issues a query for “weather in San Francisco”. The test will verify that Google returns search results, and that the first result returned is giving the weather in San Francisco.

public class SimpleGoogleTest extends ActivityInstrumentationTestCase2<SimpleAppActivity> {

public void testGoogleShouldWork() {
// Create a WebDriver instance with the activity in which we want the test to run
WebDriver driver = new AndroidDriver(getActivity());
// Let’s open a web page

// Lookup for the search box by its name
WebElement searchBox = driver.findElement("q"));

// Enter a search query and submit
searchBox.sendKeys("weather in san francisco");

// Making sure that Google shows 11 results
WebElement resultSection = driver.findElement("ires"));
List<WebElement> searchResults = resultSection.findElements(By.tagName("li"));
assertEquals(11, searchResults.size());

// Let’s ensure that the first result shown is the weather widget
WebElement weatherWidget = searchResults.get(0);
assertTrue(weatherWidget.getText().contains("Weather for San Francisco, CA"));

Now let’s see our test in action! WebDriver will create a WebView with the same configuration as the Android browser in the main UI thread, i.e. the activity thread. The activity will display the WebView on the screen, allowing you to see your web application as the test code is executing.

Interaction Testing

We’ve mentioned that WebDriver supports creating advanced gestures to interact with the device. Let’s use WebDriver to throw an image across the screen by flicking horizontally, and ensure that the next image in the gallery is displayed.

WebElement toFlick = driver.findElement("image"));
// 400 pixels left at normal speed
Action flick = getBuilder(driver).flick(toFlick, 0, -400, FlickAction.SPEED_NORMAL)
WebElement secondImage = driver.findElement(“secondImage”);

Now, let’s rotate the screen and ensure that the image displayed on screen is resized.

assertEquals(landscapeSize, secondImage.getSize())
((Rotatable) driver).rotate(ScreenOrientation.PORTRAIT);
assertEquals(portraitSize, secondImage.getSize());

What if your test reveals a bug? You can easily take a screenshot for help in future debugging:

File tempFile = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE);

Find Out More

If this has whetted your appetite and you’d like to know more, go ahead and install the Android WebDriver, take a look at the documentation on the Selenium project’s wiki, or just browse the javadocs. For questions and feedback not only of the Android WebDriver but also its desktop brethren, please join For announcements keep an eye on


Wednesday, October 26, 2011

[Gd] Stable Channel Update

| More

Chrome Releases: Stable Channel Update

The Stable channel has been updated to 15.0.874.106 for Windows, Mac, Linux, and Chrome Frame.  This release fixes login issues to Barrons Online and The Wall Street Journal (Issue 101274).

Karen Grunberg
Google Chrome

[Gd] Dev Channel Update

| More

Chrome Releases: Dev Channel Update

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

Full details about what changes are in this build are available in the SVN revision log.  Interested in switching to the Beta or Stable channels?  Find out how.  If you find a new issue, please let us know by filing a bug.

Anthony Laforge
Google Chrome

[Gd] Changes to Library Projects in Android SDK Tools, r14

| More

Android Developers Blog: Changes to Library Projects in Android SDK Tools, r14

Last week, we released the SDK for Android 4.0 and a new set of developer tools, now in revision 14. The updated tools include a lot of build changes, many that improve build performance. Also included is an under-the-hood change in how libraries are used by main projects — a first step in improving library support and code reusability. While the change should have little impact on existing projects, some developers have had issues when migrating to the updated tools. Please read below for more information about the change to library projects and how to solve migration issues.

Previously, library projects were handled as extra resource and source code folders to be used when compiling the resources and the application’s source respectively. While this worked fine for most cases, there were two issues.

1. Developers asked us for the ability to distribute a library as a single jar file that included both compiled code and resources. The nature of Android resources, with their compiled IDs prevented this.

2. The implementation of the library projects was extremely fragile in Eclipse. Adding extra source folders outside of the project folders is non-trivial when it needs to be handled automatically, in a way that doesn’t expose a user’s local installation path (which is required for people working in teams through a source control system such as SVN or git).

For r14, we decided to fix both issues at once, by moving to a compiled-code based library mechanism. This solves the implementation fragility in Eclipse and will allow us to, later, enable distribution of libraries as a single jar file.

As you might have seen in the release notes, moving to this new mechanism can affect existing projects in some cases, but there are simple fixes.

The first impact of this change is that the new library project requires the resource IDs generated by libraries to be non final. This prevents the Java compiler from inlining the values in the library code, and therefore prevents usage of the switch statement in the library code. To address such occurrences in your code, Eclipse provides a refactoring action to convert from switch statements to if/else (see here).

Second, some projects may not have been properly migrated to the new mechanism, resulting in projects that fail to compile, with errors such as duplicated classes being added in the dex build step. ADT 14 should have migrated older projects to the new mechanism but the fragility of the old mechanism may have prevented it from happening. This makes projects reference the libraries twice, using both the old and new mechanisms, which then triggers the libraries classes being packaged twice. If you see this in your projects, look in the Package Explorer for extraneous source folders named with the pattern <libraryname>_src. The screenshot to the right shows an example of this.

To fix the project, you must remove the extraneous source folders with the following steps:

  • Right click source folder and choose Build Path > Remove from Build path
  • A dialog will pop up. In it, make sure to check “Also unlink the folder from the project” to completely remove the folder.

With this change to library projects, we pave the way to better support for reusable components. We will continue working to make components easier to create, work with, and manage. Our goal is to make it easy for developers to create apps with great user experiences that easily adapt to all form factors.

Some developers have also told us that they only use library projects internally, that they don’t need to distribute binary versions and would prefer to continue with a source-based mechanism. We are investigating how we could support this alongside the new mechanism.

Finally, I wanted to point out that we are tracking a few known issues (and workaround for them) in the current r14 tools at this page:

We are working on a tools update that will include fixes for most of these. We are hoping to have it out shortly.


Tuesday, October 25, 2011

[Gd] Chrome Stable Release

| More

Chrome Releases: Chrome Stable Release

The Google Chrome team is happy to announce the arrival of Chrome 15.0.874.102 to the Stable Channel for Windows, Mac, Linux, and Chrome Frame.  Chrome 15 contains some really great improvements including a new New Tab page.

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.

  • [$500] [86758] High CVE-2011-2845: URL bar spoof in history handling. Credit to Jordi Chancel.
  • [88949] Medium CVE-2011-3875: URL bar spoof with drag+drop of URLs. Credit to Jordi Chancel.
  • [90217] Low CVE-2011-3876: Avoid stripping whitespace at the end of download filenames. Credit to Marc Novak.
  • [91218] Low CVE-2011-3877: XSS in appcache internals page. Credit to Google Chrome Security Team (Tom Sepez) plus independent discovery by Juho Nurminen.
  • [94487] Medium CVE-2011-3878: Race condition in worker process initialization. Credit to miaubiz.
  • [95374] Low CVE-2011-3879: Avoid redirect to chrome scheme URIs. Credit to Masato Kinugawa.
  • [95992] Low CVE-2011-3880: Don’t permit as a HTTP header delimiter. Credit to Vladimir Vorontsov, ONsec company.
  • [$12174] [96047] [96885] [98053] [99512] [99750] High CVE-2011-3881: Cross-origin policy violations. Credit to Sergey Glazunov.
  • [96292] High CVE-2011-3882: Use-after-free in media buffer handling. Credit to Google Chrome Security Team (Inferno).
  • [$1000] [96902] High CVE-2011-3883: Use-after-free in counter handling. Credit to miaubiz.
  • [97148] High CVE-2011-3884: Timing issues in DOM traversal. Credit to Brian Ryner of the Chromium development community.
  • [$6337] [97599] [98064] [98556] [99294] [99880] [100059] High CVE-2011-3885: Stale style bugs leading to use-after-free. Credit to miaubiz.
  • [$2000] [98773] [99167] High CVE-2011-3886: Out of bounds writes in v8. Credit to Christian Holler.
  • [$1500] [98407] Medium CVE-2011-3887: Cookie theft with javascript URIs. Credit to Sergey Glazunov.
  • [$1000] [99138] High CVE-2011-3888: Use-after-free with plug-in and editing. Credit to miaubiz.
  • [$2000] [99211] High CVE-2011-3889: Heap overflow in Web Audio. Credit to miaubiz.
  • [99553] High CVE-2011-3890: Use-after-free in video source handling. Credit to Ami Fischman of the Chromium development community.
  • [100332] High CVE-2011-3891: Exposure of internal v8 functions. Credit to Steven Keuchel of the Chromium development community plus independent discovery by Daniel Divricean.
The bugs [94487], [96292], [96902], [97599], [98064], [98556], [99294], [100059], [99138] and [99211] were detected using AddressSanitizer.

Although Chrome is not directly affected by the attack, the NSS network library was updated to include a defense against so-called BEAST. This defense may expose bugs in Brocade hardware. Brocade is working on the issue. The lighttpd project fixed a compatibility issue at version 1.4.27 and newer.

In addition, we would like to thank Sławomir Błażek and Aki Helin of OUSPG for working with us in the development cycle and preventing bugs from ever reaching the stable channel. Various rewards were issued.

Karen Grunberg
Google Chrome