Planet Chromium

Stable Channel Update for Chromebooks

2012-02-24T15:24:38+00:00

The Stable channel has been updated to 17.0.963.60 (Platform version: 1412.205.0) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48).

Release highlights:

Pepper flash: release 11.1.31.310
Stability & security fixes

Known issues:

Deleting 802.1x cert might require a restart to restore access to other wifi networks

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

Orit Mazor
Google Chrome

Chrome for Android Beta Update

2012-02-24T14:57:21+00:00

Chrome for Android Beta has been updated to 0.16.4215.215, picking up changes that have gone in through Chrome 16.0.912.77. Beyond the Chrome changes, this update contains:

Android Beam support - now beam URLs from Chrome to other devices with NFC.
Support for additional countries
Compatibility checks to ensure system prerequisites for Chrome are met
Essential bug fixes

Known issues

112923 : No way to toggle between mobile/desktop UA

113140 : Youtube Links Do Not Prompt For Which Application to Use

113132 : Chrome for Android beta doesn't support configured proxy in wi-fi settings

Other notable issues listed here

If you find a new issue, please let us know by filing a bug.

Srikanth Rajagopalan
Google Chrome

Dev Channel Update

2012-02-23T16:16:00+00:00

The Dev channel has been updated to 19.0.1049.3 for Windows, Mac, Linux and Chrome Frame. This build contains following stability and bug fixes:

All

Updated V8 - 3.9.8.0
Marked the Certum Trusted Network CA as an issuer of extended-validation (EV) certificates.
Fixed importing of bookmarks, history, etc. from Firefox 10+.
Fixed issues - 114001, 110785, 114168, 114598, 111663, 113636, 112676

Mac

Worked around lockups of mid-2010 MacBook Pros (dual NVIDIA/Intel GPUs) running 10.7. Please stress test Flash, WebGL and other GPU accelerated content on such machines and file bugs referencing Issue 113703 if issue persists.

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

Dharani Govindan
Google Chrome

Beta Channel Update for Chromebooks

2012-02-23T08:58:03+00:00

The Beta channel has been updated to 18.0.1025.39 (Platform versions: 1660.44.0) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48).

This build contains a number of stability and performance improvements. Some highlights of these changes are:

23036 - Caps lock is now triggered via the Shift + Search key combination (instead of the double Shift key combination).
20187 - Fix to reduce machine login time
Two finger click when resting/hovering thumb present fixed (users would see 3 finger clicks instead); Faulty 3 finger click turned off to correct this issue.
25133 - Fix to keyboard tab focus moving too far on login screen.
26201 - Fix to brightness filter in Chrome OS Photo Editor

Known issues:

26278 - Modal dialogs not always rendered properly.

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.

Danielle Drew
Google Chrome

The end

2012-02-22T15:46:00+00:00

No posts for six months! I have some reasons.

I started at Google in 2004. When I was hired they asked me to describe in broad terms what I wanted to work on. I remember writing back: "I've read rumors of Google working on a Linux-based operating system, which would be a perfect match for my skills and interests. Failing that, I studied linguistics so something involving language would be nice." My friend Tessa (also newly hired) and I drove down to Silicon Valley together.

I ended up in search ranking (with Tessa, even in the same office at first) for a few years. It was the experience I came to Google for: helping people smarter than me write mapreduces over terabytes to compute tricky math over language (much of my time on this project). But when I learned Google was finally working on the long-rumored browser I knew it was the project for me, to make a browser for Linux that was awesome.

We did just that. Some years passed and now somewhere near one in five people on the internet use Chrome. (With a rounding error's fraction of them on Linux, but it is my rounding error.) I learned so much about so many things, from software engineering to graphics performance to binary internals.

But I also learned that most complaints you ever read about making software for desktop Linux are correct. Before we'd jokingly say "year of Linux on the desktop!" and laugh about how it would never happen, but my smiles had become bitter. A short way to put it is that writing high-quality software is not really a goal of the platform; stuff that doesn't matter like continuously rewriting atop ever-changing platforms is. The scrappiness and free software spirit is what makes me love Linux as a hacker but I recognize now a deeper doom, that it will only ever broadly succeed by removing that spirit (e.g. Android). Maybe another way of saying all this is that I grew up.

The Chrome team grew up, too. My fondest memory of Chrome is when we started our San Francisco office, five of us crammed into a three person room and hacking at full speed. (At one point the first page of our now 95-page ohloh leaderboard was our office plus the Linux guys to the south.) But visit build.chromium.org now and observe the many configurations; visit chromium-dev now and witness tens of opinions on trivial matters; try to build Chrome now and discover you need to download literally gigabytes of source.

Those are challenges, sure, but I found I was taking them personally. I was too personally invested in the project. I gradually became a grumpy, complainy person, the sort I wouldn't like to work with. I took a three month sabbatical, came back, and found I still felt the same way. With time to reflect I wonder if the way I want to work is simply incompatible with a large team.

And so I'm moving on, to a smaller team. Coincidentally, Tessa's team. If you want to follow my future endeavors you can read my other blog.

Beta Channel Update

2012-02-21T16:22:37+00:00

The Beta channel has been updated to 18.0.1025.39 for Windows, Mac, Linux and Chrome Frame platforms

All

Updated V8 - 3.8.9.8
Fixed several crashes (Issues: 111376, 108688, 114391)
Fixed Firefox browser in Import Bookmarks and Settings drop-down (Issue: 114476)
Sync: Sessions aren't associating pre-existing tabs (Issue: 113319)
Fixed All "Extensions" make an entry under the "NTP Apps" page (Issue: 113672)

Windows

Print Dialog Partly Off Screen w/ Windows 7 Vertical Taskbar (Issue: 112614)
"Recently Closed" menu is missing after restarting Chrome (Issue: 110785)
Fixed Garbled text on the SSL chip displayed in the Omnibox (Issue: 114168)

Mac

Fixed Custom cursor decoding with wrong color (Issue: 114598)
Fixed Custom image cursor makes the cursor disappear altogether (Issue: 111027)
Fixed Chrome on dual-GPU NVIDIA/Intel MacBook Pro hangs browser (Issue 113703)

More details about additional changes are available in the svn log of all revisions. If you find a new issue, please let us know by filing a bug.

Karen Grunberg
Google Chrome

Beta Channel Update

2012-02-21T15:34:37+00:00

The Beta channel has been updated to 18.0.1025.33 for Windows, Mac, Linux and Chrome Frame platforms

All

Updated V8 - 3.8.9.6
Fixed several crashes (Issues: 110943, 110234, 110176, 108986)
Sync: Conflicting sync entries should not be committed (Issue: 82236)
Back button frequently hangs (Issue: 93427)
Fixed Speech input bubble borders don't closing (Issues: 98323, 112194)
Improved the quality of the omnibox

Mac

Fixed Gap between download shelf and vertical scrollbar (Issue: 111266)

More details about additional changes are available in the svn log of all revisions. If you find a new issue, please let us know by filing a bug.

Karen Grunberg
Google Chrome

Beta Channel Update for Chromebooks

2012-02-21T08:47:40+00:00

The Beta channel has been updated to 18.0.1025.32 (Platform versions: 1660.34.0) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48).

This build contains a number of new features, as well as security & stability improvements. Some highlights of these changes are:

Updated Pepper Flash version
Improvement to wifi stability
Improved system hardening [Yama support, etc]
File manager improvements
Crash fixes

Known issues:

25971 - Occasionally when switching tabs, the screen will not redraw the content to the new tab. Occurs most frequently when one tab contains Flash content. Workaround: Closing all tabs or restarting the machine resolves the issue.

Last week in WebKit: calculated CSS values and the translate attribute

2012-02-20T23:36:29+00:00

684 commits landed in WebKit’s repository over the course of last week, bringing several new features and improvements such as a color picker for Web Inspector, two new CSS properties and the “translate” attribute for all HTML elements.

Brian Grinstead’s color picker is now enabled by default in WebKit nightlies, following some slight polishing. To aid the undo and redo system, an event has been added to monitor CSS modifications, percentage calculation for empty heap snapshots has been fixed and the first UI for managing IndexedDB databases is available. The free-flow DOM editing experiment has ended, concluding that it wasn’t an optimal solution for highly dynamic pages. Single-click CSS editing got enabled by default, and the Elements Panel will now show previews for images.

Per Mike’s commit, basic usage of CSS’ calc() function have started to work in WebKit. Two new CSS properties have been added, -webkit-line-grid to support the alignment of lines in the inline direction to the line grid and -webkit-overflow-scrolling, indicating that an element with overflow scrolling should follow the platform’s behavior. Nested horizontal flexboxes for the new implementation have been fixed, the nowrap value for the flex-wrap property has been renamed to “none” and the computed style for auto flex-item-align now resolves to its parent’s flex-align.

All HTML elements now support the translate attribute. Support for the DOM Level 3 FocusEvent class has been added and the “types” attribute for HTML5′s drag and drop Clipboard object now returns a DOMStringList. As for CSS Regions, it’s now possible to check whether a named flow overflows and update the regionOverflow property for all elements. Finally, a repaint issue and a text selection issue related to Regions have been fixed as well.

Other changes which occurred last week:

CSS Animations can now be driven through requestAnimationFrame, evading the 40Hz rendering limit.
Following the actual implementation, an API is now available to invert colors on WebKit’s Windows port.
<mark> elements now expose their highlighted state and the <summary>element has been made keyboard accessible.
Certain XMLHttpRequest resources can now be re-used from the memory cache.
Apple’s WebKit ports have switched to using the RFC6455 protocol for WebSockets.
Fat Fingers is now responsible for touch accuracy in BlackBerry’s WebKit port.
Support for CSS Regions is now run-time toggleable, and may be disabled for Chromium.
Scoped selector matching has been implemented in the CSS slow path.

This is the first article in a weekly series highlighting the WebKit changes which occur during during a given week. Of course there are many other changes landing as well, which the Trac Timeline provides a great overview of!

Calculated CSS Values, a Color Picker and the Translate Attribute

2012-02-20T23:30:09+00:00

Another 1,642 changes landed in the repositories last week, 958 for Chromium and 684 for WebKit. Highlights include a color picker for Web Inspector and early functionality for the calc() function.

Brian Grinstead’s color picker is now enabled by default in WebKit nightlies, following some slight polishing. To aid the undo and redo system, an event has been added to monitor CSS modifications, percentage calculation for empty heap snapshotshas been fixed and the first UI for managing IndexedDB databases is available. The free-flow DOM editing experiment has ended, concluding that it wasn’t an optimal solution for highly dynamic pages. Single-click CSS editing did however get enabled by default, and the Elements Panel will now show previews for images.

Other changes which occurred last week:

CSS Animations can now be driven through requestAnimationFrame, evading the 40Hz limit.
Following the actual implementation, an API is now available to invert colors on the Windows port.
Inverting colors is coming to Chromium as well, now supported for non-accelerated content.
<mark> elements now expose their highlighted state and <summary> has been made keyboard accessible.
The right MSAA role for tab-related content will now be set within Chromium.
Certain XMLHttpRequest resources can now be re-used from the memory cache.
Apple’s WebKit ports have also switched over to using the RFC6455 protocol for WebSockets.
The “OK” button will now be focused again in JavaScript dialogs displayed from Chromium.
Fat Fingers is now responsible for touch accuracy in BlackBerry’s WebKit port.
Support for CSS Regions can now be toggled during run-time, and may be disabled for Chromium.
Chromium on Linux will now display the profile avatar or Incognito emblem in the window icon.
Scoped selector matching has been implemented in the CSS slow path.

And that was an update from London again, thanks for reading!

Alejandro García is a WebKit reviewer!

2012-02-20T14:55:07+00:00

In the last couple of years Alex, as we call him, helped with the WebKitGTK+ port maintenance from bugfixing to testing or releasing. He also contributed some improvements to the shadow rendering performance and lately he started the integration of WebKit2 GTK+ port, helping also with the integration of the accelerated compositing in the GTK+ port.

Please join me in congratulating Alejandro on his new role as a WebKit reviewer!

Chrome Stable Update

2012-02-17T13:04:44+00:00

The Chrome Stable channel has been updated to 17.0.963.56 on Windows, Mac, Linux and Chrome Frame. This release fixes a number of stability and security issues in Chrome, and also includes a new version of Flash. More info on the Flash update is available from Adobe.

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.

[105803] High CVE-2011-3015: Integer overflows in PDF codecs. Credit to Google Chrome Security Team (scarybeasts).
[$500] [106336] Medium CVE-2011-3016: Read-after-free with counter nodes. Credit to miaubiz.
[$1000] [108695] High CVE-2011-3017: Possible use-after-free in database handling. Credit to miaubiz.
[$1000] [110172] High CVE-2011-3018: Heap overflow in path rendering. Credit to Aki Helin of OUSPG.
[110849] High CVE-2011-3019: Heap buffer overflow in MKV handling. Credit to Google Chrome Security Team (scarybeasts) and Mateusz Jurczyk / Gynvael Coldwind of the Google Security Team.
[111575] Medium CVE-2011-3020: Native client validator error. Credit to Nick Bray of the Chromium development community.
[$1000] [111779] High CVE-2011-3021: Use-after-free in subframe loading. Credit to Arthur Gerkis.
[112236] Medium CVE-2011-3022: Inappropriate use of http for translation script. Credit to Google Chrome Security Team (Jorge Obes).
[$500] [112259] Medium CVE-2011-3023: Use-after-free with drag and drop. Credit to pa_kt.
[112451] Low CVE-2011-3024: Browser crash with empty x509 certificate. Credit to chrometot.
[$500] [112670] Medium CVE-2011-3025: Out-of-bounds read in h.264 parsing. Credit to Sławomir Błażek.
[$1337] [112822] High CVE-2011-3026: Integer overflow / truncation in libpng. Credit to Jüri Aedla.
[$1000] [112847] High CVE-2011-3027: Bad cast in column handling. Credit to miaubiz.

The bugs [106336], [106336], [110172], [110849], [111779] and [112847] were detected using AddressSanitizer.

More detailed updates are available on the Chrome Blog. Full details about what changes are in this release are available in the SVN revision log. Interested in hopping on the stable channel? Find out how. If you find a new issue, please let us know by filing a bug.

Jason Kersey
Google Chrome

Dev Channel Update for Chromebooks

2012-02-16T14:58:52+00:00

The Dev channel has been updated to 18.0.1025.32 (Platform versions: 1660.34.0) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48).

This build contains a number of stability improvements. Additional changes:

24450 - For users enrolled in an enterprise, the time zone setting is now editable by any user.
25604, 20612- Fixes issues where using an incorrect proxy, or when there is limited connectivity would cause a spinner icon to be infinitely shown on the login screen.
26127 - Fixes issues with streaming videos not being able to play in full screen mode.
Crash fixes

Known issues:

25971 - Occasionally when switching tabs, the screen will not redraw the content to the new tab. Occurs most frequently when one tab contains Flash content. Workaround: Closing all tabs or restarting the machine resolves the issue.

Stable Channel Update for Chromebooks

2012-02-16T11:28:05+00:00

The Google Chrome team is happy to announce the release of Chrome 17 on the Stable Channel for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48). You can read more about the Chrome version 17.0.963.54 (Platform version: 1412.186.0)

Release highlights:

Read about improvements to Chrome over on the Google Chome blog
Fixed CVE-2012-0056 kernel: proc: /proc/<pid>/mem mem_write insufficient permission checking
Verizon activation and top-up portal
Update Pepper Flash
New photo editor
File browser improvements
OpenVPN support
Stability & security fixes

Tech preview of Chromium with Dart engine now available

2012-02-16T09:32:49+00:00

Cross posted to the Google Code Blog

An attractive feature of Web programming is a rapid development cycle. Reloading the application after the source code has changed takes a fraction of a second. We want to offer you that same experience when using Dart, and today we’re making Mac and Linux binaries available that integrate the Dart VM into Chromium.

This technology preview allows you to run your Dart programs directly on the Dart VM in Chromium and avoid a separate compilation step. Over time, these programs will take advantage of the VM’s faster performance and lower startup latency.

Dart has been designed from the start to work with the entire modern web, and we’re simultaneously continuing to improve our fast Dart-to-JavaScript compiler. Both the Dart VM and modern JavaScript engines are first-class targets for Dart.

This release of Chromium with Dart VM integration is a technology preview, and should not be used for day-to-day browsing. After more testing and developer feedback, we plan to eventually include the Dart VM in Chrome.

Today’s release of the Chromium + Dart VM integration is another step forward for the open source "batteries included" Dart platform. Our goal is to help you build complex, high performance apps for the modern web, and we encourage you to try Dart and let us know what you think.

Posted by Anton Muhin, Vijay Menon, and Pavel Podivilov, Software Engineers

Thou shalt not kill

2012-02-16T08:56:22+00:00

The recent beta release of Chrome on Android marks a great time to look at what happens when web applications consume too much memory: something gets killed.

Previously I've blogged about the importance for web developers to mind their memory usage. On powerful desktop machines enjoyed by many developers, this can seem like an academic concern. But on mobile devices the limitation is all too real. Case in point: I compile with 24G of RAM and deploy to a Nexus S with 512M, and of that, only two-thirds (about 342M) is available for the system to use.

Here's what happens as a web app approaches that 342M limit.

1. Android apps are killed

The Android system has a wonderful design in which the user doesn't need to be concerned with which apps are open at any given time. The system has the prerogative to pause and resume background apps based on available resources. So, the first thing that happens as a web app's memory usage grows is that background applications are gracefully paused and killed. This is normal operation which happens constantly, however, it does mean that users wait longer when switching to paused apps as they have to be restarted and resumed.

2. Chrome tabs are killed

Once the system has given Chrome as much memory as it can afford, it sends notifications as usage approaches the limit. When Chrome notices it is using too much memory or receives one of these notifications, it has no choice but to kill background tabs. This is a little less transparent to users because when the user switches back to a killed tab, instead of the usual near instantaneous switch, the page must be reloaded from cache or network.

3. Caches are cleared

Up until this point, memory pressure has caused some performance problems for the user, but the foreground content hasn't suffered much. However, after all background tabs have been killed, Chrome's only remaining recourse is to clear memory caches and perform additional V8 garbage collections. This begins to cut into the application's interactive performance (scrolling, animations, JavaScript responsiveness, etc). It is often a short lived fix as these caches can quickly refill. A high performing web application should never allow memory usage get this high.

4. Suicide

Finally, when the system can allocate memory no more, it kills Chrome's renderer process in which the web page lives. Many mobile browsers would crash entirely, but due to Chrome's unique multiprocess architecture, the browser keeps running and displays the "Aw, Snap!" page. The user, left frustrated, is free to quickly move on to a better performing web page.

Living a long life

Possibly my favorite feature of Chrome on Android is that the entire developer tools suite works through remote debugging. This makes it easy to keep an eye on memory usage and diagnose memory leaks when they do occur.

Dev Channel Update

2012-02-14T17:16:43+00:00

The Dev channel has been updated to 19.0.1041.0 for Windows, Mac, Linux and Chrome Frame. This build contains following stability and bug fixes:

Make speech input bubble borders close with the bubble [Issue: 112194]
Fixed stability issues [Issues: 113531, 113492, 113654, 113546, 113847, 114011]

Changes in Chrome Web Store categories system

2012-02-14T13:01:14+00:00

When we launched the Chrome Web Store a year ago, our app taxonomy system reflected the apps that were available in the store at the time. However, since then, the store’s app inventory has grown and changed in composition. So, yesterday we made important changes in the Chrome Web Store’s app category system to allow more great apps of all kinds to stand out.

Until now, you could list your app into two categories. With the new category structure, we will show your app only in the primary category that you select for your app in the developer dashboard. We've found that secondary app categories contributed to a confusing experience for Chrome users and developers so from now on, we're going to start ignoring the secondary category.

We also updated the list of top level app categories and created multiple sub categories in each of them.

More specifically, given the growing use of Chrome and Chromebooks in large and small businesses, we created a new category called “Business Tools” that can help enterprise focused developers target these users. Also, “Shopping” has been reclassified as a subcategory, within the “Lifestyle” category.

The new structure of the store will improve discoverability for apps. For example, users searching for a photo album app can now easily drill down to the “Photos” subcategory level and track down the app they are looking for. At the same time, apps assigned to a subcategory show up in the category page as well giving them wider exposure; an app in "Photos" will appear on both the "Photos" page and the "Entertainment" page.

The categories will continue to evolve over time. To that effect, in the Developer Dashboard you will see a few more subcategory options than the ones that are live in the Chrome Web Store today. We plan to expose these subcategories to users once we confirm we have enough interesting apps in each one of them. In the meantime, items assigned to these subcategories will show up at a related subcategory. For example all items on “Online Documents & File Storage” will show up for now in “Office Tools”.

This transition required our team to take a stab at automatically assigning all apps to one of our new categories / subcategories. Please take a look at the developer dashboard and make sure the placement of your app accurately reflects your business goals and the experience you offer.

Learn more about these category changes on our developer site. If you have any questions about these changes, please don't hesitate to post to our developer forum.

Posted by Jia Tam, Software Engineer

Mutation Observers, Reversed Animations and Faster JPEGs

2012-02-13T23:29:43+00:00

With 995 commits to Chromium’s repository and 754 to WebKit’s, last week brought in another 1,749 changes to the projects. Highlights include Mutation Observers being enabled for all WebKit ports and reversed CSS Animations.

Web Inspector’s Heap Profiler overview screen got some UI improvements and will now show percentages by default next to absolute usage numbers. Hovering over elements with :hover styles defined won’t lock up anymore, the debug side-bar in the Script Panel can now be hidden and DOM edits can now be undone. Brian Grinstead contributed a color picker, bridging the gap until actual <input type=color> gains support. Touch events are now supported by Web Inspector, and can be enabled through the Settings panel.

Mutation Observers have been enabled by default on all WebKit ports. The click() method is now implemented on HTMLElement, making it available for all elements in the DOM. URLs specified in <a ping> won’t be lowercased anymore, the state attribute has been added to the History’s DOM interface and the MediaStream API now supports the onstatechange event for PeerConnection. Finally, the Shadow DOM’s <shadow> element has been added.

Reverse directions for CSS Animations are now available. The calc() function can now, in limited fashion, be used with the hsl() and rgb() functions, and no longer supports the mod operator. Flexboxes can now center and refactorings are being done in preparation of multi-line support. unicode-bidi: plaintext is now supported for inline elements and line-grid-snap has been renamed line-snap.

With 41 commits in total, Haraken did another round of IDL cleanups.

Other changes which occurred last week:

Work on getting CSS Filters to Chromium’s accelerated layers is being done.
Apple has landed support for hardware accelerated CSS Filter animation.
Decoding of JPEG images has been improved by 9% on Chromium.
A framework for WebSocket extensions (i.e. per-frame compression) has landed.
Multisampling for Safari’s WebGL for ATI cards running on Mac OS X 10.7.2 or later.
The score calculations for ranking auto-complete shortcut providers has been updated.
Besides SwiftShader for Windows, Aura seems to be experimenting with LLVMPipe.
WebGL is now able to report errors to Web Inspector’s console.
Due to improved style sharing, certain page cycler tests have been sped up.
Asking Google for spelling suggestions in Chromium is now possible on all platforms.
Directionality for script-triggered dialog boxes has been aligned with the HTML specification.
Lots of updated SVG Tests by WildFox, using a new method to wait for the first draw.
An FFTFrame implementation based on Intel’s IPP library got added.
Chris Rogers is now a WebKit reviewer, congratulations!

And that’ll be today’s update live from Mountain View .

Beta Channel Update for Chromebooks

2012-02-13T20:43:13+00:00

The Beta channel has been updated to 17.0.963.54 (Platform versions: 1412.186) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48).

This update fixes a number of stability and UI issues.

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.

Orit Mazor
Google Chrome

New resources for Chrome Developers

2012-02-13T14:01:18+00:00

All good things come in threes. So, this week, the Chrome Developer Relations team is releasing three new resources for developers.

First, we are making available a brand new Field Guide to Web Applications, to help developers create great web apps. This guide walks you through topics like app design fundamentals, tips for creating great experiences and a few case studies that put the best practices to use. Whether you're building your first web app or are just looking for ways to improve your existing apps, we hope you'll find the field guide useful.

Second, our popular HTML5 site, HTML5Rocks.com, was also remodeled to better organize the site's content. You’ll now find new "persona pages" with catered content in 3 different verticals (Games, Business, Mobile). In addition, we consolidated many of the different components, and deeply integrated the HTML5 technology classes to bring a better identity to the site.

Finally, we've also joined Google+ with a new page specifically for Chrome Developers. Whether you’re building modern web apps, using Dart or WebRTC, we’ll be there to help you! Keep your eyes open for our weekly hangouts and add us to your circles.

Posted by Eric Bidelman & Pete LePage

RSA 2012

2012-02-12T08:00:00+00:00

Just a brief note that I'll be at RSA 2012 in San Francisco at the end of the month and will be speaking with several others about certificate revocation. (tech-106, Tuesday, 1pm.).

If you want to chat and don't manage to grab me then, drop me an email. (agl at imperialviolet.org if you didn't already know.)

Dev Channel Update for Chromebooks

2012-02-10T15:59:35+00:00

The Dev channel has been updated to 18.0.1025.29 (Platform versions: 1660.20.0) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48).

This build contains a number of stability improvements. Additional changes:

Updated Pepper Flash version
25865 - Fixes to crashes generated and blank screen being seen after browser crash
Improvements to video playback from File Browser

Known issues:

Issue on signing out: Please note that in some circumstances if you are connected via a proxy, signing out of your Chrome OS session may not work. Users may see 8 or more seconds of a blank screen followed by being returned to the previous signed in state. If you encounter this problem, please submit a feedback report (Wrench > Report an Issue) mentioning this issue. Please include the tag '#CantSignOut' and the approximate time you encountered this issue. Workaround: Shutdown the machine using either the power button or the Wrench menu > Sign out option, and restart the machine to login as a different user.
26127: Videos do not play in full screen mode. This affects multiple sites including YouTube and others.

Dev Channel Update

2012-02-10T14:21:56+00:00

The Dev channel has been updated to 19.0.1036.7 for Windows, Mac, Linux and Chrome Frame. This build contains following updates:

All

Updated V8 - 3.9.4.0
Fix: open incognito windows at exit created extra normal windows when the session was restored [r120554]
Show spelling suggestions for misspelled words from the online spellchecker provided by Google (only after users opt into sending text to the service) (r120959).
When translating a page, get the code and translation via HTTPS. (r120113)

Windows

Fix a visual artifact when UI bubbles fade [r119916]
Fix an infrequent crash on repaint [r120196]
Fix 3D acceleration on computers with NVIDIA Optimus graphics [r120651]
Use Google’s online spellchecker to identify misspelled words as well as provide suggestions, for pasted text only. (r120959).
Fixed a crash that could occur if a page was closed while playing audio [r120749].

Linux

Use Google’s online spellchecker to identify misspelled words as well as provide suggestions, for pasted text only. (r120959).

Known Issues

Sub-dialogs do not work in Settings [Issue: 113505, et al].

The Future of JavaScript – take a peek today!

2012-02-10T09:26:38+00:00

The ECMA committee is working hard on designing the next version of JavaScript, also known as "Harmony". It is due by the end of next year and it is going to be the most comprehensive upgrade in the history of this language.

Chrome and V8 are committed to pushing JavaScript forward and have already started implementing the new features. You can try some of them today in the latest dev channel release. Here’s a summary:

Lexical scoping. Now "let" is the new "var" – traditional "var" declarations are complemented with "let" and "const". Both are properly block-scoped bindings, eliminating a common source of errors and weird behaviour. Function declarations are now officially allowed in local scope as well, and also obey lexical scoping. (Note: Lexical scoping is only available in ES strict mode.)

Collections. Efficient maps and sets will make your life easier. Any value can be used as a key or element, including objects. No surprises, no more need to abuse objects as dictionaries. (Caveat: Iteration over collections is not yet specified.)

Weak maps. A special kind of map for which the garbage collector determines when a key is no longer reachable, so that the key-value pair can be removed from the map automatically. This goes a long way towards avoiding memory leaks in long-lived tables and relieves the developer from worrying about stale entries.

Proxies. A proxy simulates a JavaScript object or function, and can customize just about any aspect of their behaviour that you can imagine. This is a real power feature, that takes reflection to a new level and can be used to implement various advanced abstractions and interfaces.

...and there is a lot more to come, as the V8 team will continue working on bringing new Harmony features to you.

To enable Harmony features in the latest dev channel release of Chrome, go to chrome://flags and toggle on "Experimental JavaScript features". We encourage you to try them out and give us feedback!

Posted by Andreas Rossberg and Michael Starzinger, Software Engineers

Snazzier graphics for more users

2012-02-09T15:03:06+00:00

Every day the web becomes more powerful, allowing developers to create the next generation of beautiful, immersive experiences online. In our latest Chrome Beta release, we’ve made a few enhancements to ensure users have a smooth ride in these graphics-intensive applications. If you want to dig into the details, clip on your pocket protector and head over to the Chromium blog.

Posted by Tom Wiltzius, Associate Product Manager and Snazz Master

Chrome Beta Release

2012-02-09T12:05:25+00:00

The Chrome team is happy to announce the arrival of Chrome 18.0.1025.11 to the Beta Channel for Windows, Mac, Linux, and Chrome Frame.

Chrome 18 contains some really great improvements including GPU accelerating 2D Canvas, and enabling 3D content for older GPUs. More on what's new at the Official Chrome Blog and the Chromium Blog.

You can find full details about the changes that are in Chrome 18 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.

Karen Grunberg
Google Chrome

GPU accelerating 2D Canvas and enabling 3D content for older GPUs

2012-02-09T12:02:22+00:00

Today’s Beta release brings 2D Canvas improvements and a software rasterizer to Chrome.

For most Windows and Mac users, we’ve enabled GPU-accelerated rendering of 2D Canvas content, so that canvas-based games and animations run faster and feel smoother. You can go to chrome://gpu to see which features are being accelerated. This is a tricky area to optimize, due to the wide variety of hardware and operating system configurations found in the wild. We’ve made a series of small improvements to the way this acceleration works in the latest release, and we're seeking feedback on it from our Beta users. If you notice performance problems with 2D Canvas graphics content, particularly if you’re a web developer using 2D Canvas on your site, please file a bug.

At the same time, we recognize that many people with older GPUs and graphics drivers have not been able to experience the rich content provided by technologies such as WebGL. Chrome is now able to display 3D content via SwiftShader, a software rasterizer we licensed from TransGaming, Inc. Although SwiftShader won’t perform as well as a real GPU, it will be an improvement for many of our users on older operating systems such as Windows XP.

SwiftShader automatically kicks in for those users who cannot run content on the GPU. If you want to take a peek at what the performance is like with SwiftShader, you can use the --blacklist-accelerated-compositing and --blacklist-webgl flags, wait a few minutes for the automatic download to complete, and then load the relevant web page.

As always, we appreciate your willingness to try out our creaky Beta software and look forward to your feedback and bug reports.

Posted by John Bauman and Brian Salomon, Software and Pixel Engineers

Expanding the Chromium Security Rewards Program

2012-02-09T09:19:17+00:00

It’s hard for us to believe, but it’s been just over two years since we first announced the Chromium Security Rewards Program.

We’ve been delighted with the program’s success; we’ve issued well over $300,000 of rewards across hundreds of qualifying bugs, all of which we promptly fixed. It also helped inspire a wave of similar efforts from companies across the web, including Google’s own vulnerability reward program for web properties, which has also been a big hit.

We’ve been fascinated by the variety and ingenuity of bugs submitted by dozens of researchers. We’ve received bugs in roughly every component, ranging from system software (Windows kernel / Mac OS X graphics libraries / GNU libc) to Chromium / WebKit code and to popular open source libraries (libxml, ffmpeg). Chromium is a more stable and robust browser thanks to the efforts of the wider security community.

Today we’re expanding the scope of the Chromium program to formally include more items that deserve recognition:

High-severity Chromium OS security bugs are now in scope. Chromium OS includes much more than just the Chromium browser, so we’re rewarding security bugs across the whole system, as long as they are high severity and present when “developer mode” is switched off. Examples of issues that may generate a reward could include (but are not limited to):

Renderer sandbox escapes via Linux kernel bugs.
Memory corruptions or cross-origin issues inside the Pepper Flash plug-in.
Serious cross-origin or memory corruption issues in default-installed apps, extensions or plug-ins.
Violations of the verified boot path.
Web- or network-reachable vulnerabilities in system libraries, daemons or drivers.

Chromium OS security bugs should be reported in the Chromium OS bug tracker, whilst security bugs affecting the desktop Chromium browser should be reported in the Chromium bug tracker.

We may elect to issue “bonuses” ranging from $500 to $1000 if a bug reporter takes on fixing the bug they have found themselves. For eligibility, this process involves working with the Chromium community to produce a peer reviewed patch. These bonuses are granted on top of the base reward, which typically runs between $500 and $3133.70.

The base reward for a well-reported and significant cross-origin bug (for example a so-called UXSS or “Universal XSS”) is now $2000.

Perhaps most importantly, this program reflects several of our core security principles: engaging the community, building defense in depth, and particularly making the web safer for everyone.

Related to this third core principle, we’re particularly excited by all the work that has been done on shared components. For example, a more robust WebKit not only helps users of two major desktop browsers, but also a variety of tablet and mobile browsers.

Posted by Chris Evans, Google Chrome Security

Chrome Fast for Android

2012-02-09T03:18:46+00:00

The Chrome Beta for Android is solid Chrome. That means it inherits my favorite speed features from its older desktop siblings. Some of them are novel to mobile browsers. For all of them, the absolute performance benefit is usually greater than on more powerful desktops.

In no particular order, here are ten I'm most excited to see together in the mobile world.

Remote debugging Probably the most important thing a browser can do to make the web fast is to provide developer tools which make it easy for web developers to build fast sites. While there have been some cutting edge projects to bring parts of DevTools to mobile, the full suite hasn't been available until now. Use the Timeline, Profiles and Network panels to find the trickiest bottlenecks.
SPDY Also supported in the stock Android Browser on Honeycomb systems and newer, SPDY significantly reduces the number of costly RTTs that are incurred during a web page load. Keep in mind it only works with servers that speak SPDY. Apache users may be interested in following the progress of mod_spdy.
Hardware accelerated graphics Getting this right was one of the largest efforts in bringing Chrome to Android. As a result, scrolling is buttery smooth on most reasonably efficient web sites. If your site isn't as smooth as you want it to be, take a profile in the Timeline panel to see where time is being spent. Often there are patterns for avoiding layouts or style recalculations to get back into the fast zone. A notable exception is CSS animations. While Chrome's framerate is similar to other mobile browsers, they aren't nearly as smooth as they need to be. Improving them is an area of focus at the moment.
V8 Crankshaft Incorporating the largest performance improvement in V8's history allows a mobile browser to hold its own against even JavaScript heavy web sites designed for the desktop.
Navigation Timing Also newly available in the stock Android Browser on Ice Cream Sandwich, support for the Navigation Timing API allows developers to understand real users' page load times. This further increases the coverage of the API which is already supported in the lastest versions of desktop Chrome, Firefox and IE.
Large persistent cache As brought to note by Guy Podjarny, most mobile browsers have very tiny disk caches. Chrome's logic is based on the amount of disk space available, which means devices with plenty of free space are able to have significantly larger caches.
requestAnimationFrame Support for this API is critical for building efficient JavaScript animations. UPDATE: Henri Sivonen points out that this was unclear. In Chrome, this API is vendor prefixed as webkitRequestAnimationFrame while it is being standardized.
Preloading Searches in the omnibox trigger the preloading of high confidence results. In many cases this results in a near instant page load. By default this is enabled only when on WiFi, and that is customizable.
SSL FalseStart This relatively recent improvement in the Chrome network stack avoids a costly RTT during the establishment of SSL connections. The commonly high RTT on mobile networks and increasing use of HTTPS on the web make this a nice win.
HTML5 APIs Support for newer HTML5 APIs like Web Sockets, Web Workers and Indexed Database provide the building blocks for building high performance web apps.

Getting Chrome running on Android is only the first step. Now the really fun stuff can begin.

Faster browsing, safer downloading

2012-02-08T12:00:03+00:00

When I visit my favorite sandwich shop, I always order the same thing: a chicken cashew salad sandwich on whole wheat (it’s awesome). Now, the owners know what I want as soon as I walk in the door. Which means they can start making it before I say a word. Which means I get my sandwich faster.

With today’s Stable release, Chrome now does the same thing. Except not with sandwiches. When you start typing in the omnibox and the URL autocompletes to a site you’re very likely to visit, Chrome will prerender the page, so it will appear faster--sometimes, even instantly--as soon as you hit Enter. To learn more, check out the post from our latest Beta release.

On the security front, Chrome now does even more to help protect you from malicious downloads. In addition to checking a list of known bad files, Chrome also does checks on executable files (like ".exe" and ".msi" files). If the executable doesn't match a whitelist, Chrome checks with Google for more information, such as whether the website you're accessing hosts a high number of malicious downloads.

In the near future, we will also begin rolling out updates to Chrome OS to further simplify the Chromebook experience. With a new image editor, Chromebook users will be able to quickly view, edit and share photos on the web. Users will also see an improved Verizon 3G activation portal, which includes the ability to set up a recurring purchase of mobile data.

If you don’t have Chrome, download it now to check out the latest features!

Posted by Noé Lutz, Software Engineer and Malware Vigilante

Stable Channel Update

2012-02-08T09:09:43+00:00

The Chrome team is excited to announce the release of Chrome 17 to the Stable Channel for Windows, Mac, Linux and Chrome Frame. 17.0.963.46 contains a number of new features including:

New Extensions APIs
Updated Omnibox Prerendering
Download Scanning Protection
Many other small changes

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

[73478] Low CVE-2011-3953: Avoid clipboard monitoring after paste event. Credit to Daniel Cheng of the Chromium development community.

[92550] Low CVE-2011-3954: Crash with excessive database usage. Credit to Collin Payne.

[93106] High CVE-2011-3955: Crash aborting an IndexDB transaction. Credit to David Grogan of the Chromium development community.

[103630] Low CVE-2011-3956: Incorrect handling of sandboxed origins inside extensions. Credit to Devdatta Akhawe, UC Berkeley.

[$1000] [104056] High CVE-2011-3957: Use-after-free in PDF garbage collection. Credit to Aki Helin of OUSPG.

[$2000] [105459] High CVE-2011-3958: Bad casts with column spans. Credit to miaubiz.

[$1000] [106441] High CVE-2011-3959: Buffer overflow in locale handling. Credit to Aki Helin of OUSPG.

[$500] [108416] Medium CVE-2011-3960: Out-of-bounds read in audio decoding. Credit to Aki Helin of OUSPG.

[$1000] [108871] Critical CVE-2011-3961: Race condition after crash of utility process. Credit to Shawn Goertzen.

[$500] [108901] Medium CVE-2011-3962: Out-of-bounds read in path clipping. Credit to Aki Helin of OUSPG.

[109094] Medium CVE-2011-3963: Out-of-bounds read in PDF fax image handling. Credit to Atte Kettunen of OUSPG.

[109245] Low CVE-2011-3964: URL bar confusion after drag + drop. Credit to Code Audit Labs of VulnHunt.com.

[109664] Low CVE-2011-3965: Crash in signature check. Credit to Sławomir Błażek.

[$1000] [109716] High CVE-2011-3966: Use-after-free in stylesheet error handling. Credit to Aki Helin of OUSPG.

[109717] Low CVE-2011-3967: Crash with unusual certificate. Credit to Ben Carrillo.

[$1000] [109743] High CVE-2011-3968: Use-after-free in CSS handling. Credit to Arthur Gerkis.

[$1000] [110112] High CVE-2011-3969: Use-after-free in SVG layout. Credit to Arthur Gerkis.

[$500] [110277] Medium CVE-2011-3970: Out-of-bounds read in libxslt. Credit to Aki Helin of OUSPG.

[$1000] [110374] High CVE-2011-3971: Use-after-free with mousemove events. Credit to Arthur Gerkis.

[110559] Medium CVE-2011-3972: Out-of-bounds read in shader translator. Credit to Google Chrome Security Team (Inferno).

The bugs [105459], [106441], [108416], [108901], [109716], [109743], [110112], [110277], [110374] and [110559] were detected using AddressSanitizer.

In addition, we would like to thank miaubiz, Drew Yao and Braden Thomas of Apple, Sławomir Błażek, Aki Helin of OUSPG, Chamal de Silva and Atte Kettunen of OUSPG for working with us in the development cycle and preventing bugs from ever reaching the stable channel. Various rewards were issued, including a top $3133.70 reward to Aki Helin.

More detailed updates are available on the Chrome Blog. Full details about what changes are in this release are available in the SVN revision log. Interested in hopping on the stable channel? Find out how. If you find a new issue, please let us know by filing a bug.

Jason Kersey
Google Chrome

Chris Rogers is a WebKit Reviewer!

2012-02-07T23:32:20+00:00

Chris Rogers is the author of the Web Audio API specification and the primary implementor of it in WebKit. Chris has also contributed to the XHR2 specification (the .responseType and .response attributes), and implemented these attributes in WebKit.

Please join me in congratulating Chris on his new role as a WebKit reviewer!

Beta Channel Update for Chromebooks

2012-02-07T19:49:22+00:00

The Beta channel has been updated to 17.0.963.51 (Platform versions: 1412.174) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48).

Dev Channel Update

2012-02-07T18:03:32+00:00

The Dev channel has been updated to 18.0.1025.7 for Windows, Mac, Linux and Chrome Frame. This build contains following stability and bug fixes:

Users can now sync NTP icons to their profile and keep their order across different instances of chrome. [Issues: 111277, 100737, 61447]
Pointer Lock / Mouse Lock is implemented behind a flag (see about:flags). Mac only bug fix when closing a tab. [Issue: 111860]
Fixed stability crashes [Issue: 112590, 112116, 111968, 110909]

Bringing Google Chrome to Android

2012-02-07T17:46:04+00:00

Finally we’re able to provide an answer to the many rumors which have been going around in the past few months: Google Chrome is now available for Android devices running Ice Cream Sandwich. On my Galaxy Nexus, the browser scores 343 points on html5test.com, runs the SunSpider test in 1880ms and scores 1308 points on the v8 test.

Support for the Web Platform
The first beta uses the same basis as Google Chrome 16, meaning it has most Chromium and WebKit changes up to mid October 2011. I’ve already iterated through many of the changes which were included in that release, most of which will apply for the Android version as well.

To name some highlights, Chrome for Android supports pretty much all of the Web Platform’s exciting features, including CSS 3D Transforms, GPU accelerated canvas, CSS Animations, SVG, WebSockets (including binary messages!) and Dedicated Workers. It supports IndexedDB, Application Cache and the File APIs, date and time pickers, parts of the Media Capture API and mobile oriented features such as Device Orientation and Geolocation. Fixed positioned elements are also working and even look smooth while scrolling!

What the Android-based Chrome does not support is Flash, following Adobe’s announcement in November. Other unsupported features in the beta release are Extensions/Apps, WebGL, Shared Web Workers and the Web Audio API.

An issue that often pops up for mobile browsers is that text on the website may be too small to read properly. Where the Android Browser employs a text reflow algorithm to clarify the situation, Chrome for Android features a technique which we’ve called Font Boosting. It uses an algorithm to increase font sizes when necessary, aiming to make the text readable regardless of the zoom level.

And for the Web Developers among you, it’s also possible to utilize Web Inspector’s Remote Debugging feature to inspect and modify pages while viewing it on the device itself.

Google Chrome 16 and mobile limitations
Of course, bringing a browser to a different -much more limited- platform goes further than simply re-using code. Mobile devices have a lot of limitations compared to desktop and laptop machines. Besides the lower amount of available memory and CPU power, other constraints lie in less memory bandwidth and VRAM on the device’s GPU. Google Chrome has a complicated architecture which imposed some interesting challenges here: separating the browser from the renderers through its multiple process architecture, to name an example. Decreased rendering and scrolling performance were also an issue, to which Chrome’s GPU team provided an excellent answer in the form of a threaded compositor.

Another characteristic of the Android platform is that the APIs for most significant features are exposed through the Android SDK, making them available to Java code. To this end, part of the browser layer has actually been implemented in Java, communicating with the rest of the Chromium and WebKit code through Java Native Bindings.

Becoming part of the Chromium project: upstreaming our code
Chrome for Android has been developed in a separate repository as a fork, which means that most of the code will have to be upstreamed. To date, about 150 commits have landed in Chromium making many preparations, including the build environment and bots for Chromium and WebKit, not to mention WebKit’s umbrella bug and the two announcements.

As having a fork is far from ideal, one of the current top priorities will be to upstream most new and modified code to Chromium and WebKit, while the build and testing infrastructure on Chromium’s waterfalls is expected to evolve significantly. A snapshot of the current source-code of Chrome for Android can be downloaded as a tarball.

Of course, keep in mind that today’s release is just a beta; much more work, features and stability will be needed to actually be able to release the first stable version. Personally, I’m very glad that the project has been announced, and definitely am looking forward to continuing development in the open!

Dev Channel Update for Chromebooks

2012-02-07T15:43:00+00:00

The Dev channel has been updated to 18.0.1025.6 (Platform versions: 1660.13.0) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48).

This build contains a number of stability improvements. Additional changes:

Introduces new Verizon activation and top-up portal featuring many user-requested improvements:

Enables recurring billing as the default for pre-paid monthly plans
Greatly simplifies the Verizon activation and top-up process
Allows purchase of additional data prior to current bundle expiration
Eliminates credit card requirement for free 100MB plan

Updated Pepper Flash version
Fix for Hangouts issue 25559

Known issues:

25592 - Sometimes when resuming the machine after closing the lid, the machine displays a blank (black backlit) screen. Restarting the machine is required.
25642 - Selecting Time & Date options from time drop-down does not display the Time & Date Settings. Workaround: Go to Under the Hood -> Advanced Settings
25971 - Occasionally when switching tabs, the screen will not redraw the content to the new tab. Workaround: Closing all tabs or restarting the machine resolves the issue.

Introducing Chrome for Android

2012-02-07T13:11:19+00:00

In 2008, we launched Google Chrome to help make the web better. We’re excited that millions of people around the world use Chrome as their primary browser and we want to keep improving that experience. Today, we're introducing Chrome for Android Beta, which brings many of the things you’ve come to love about Chrome to your Android 4.0 Ice Cream Sandwich phone or tablet. Like the desktop version, Chrome for Android Beta is focused on speed and simplicity, but it also features seamless sign-in and sync so you can take your personalized web browsing experience with you wherever you go, across devices.

Speed

With Chrome for Android, you can search, navigate and browse fast—Chrome fast. You can scroll through web pages as quickly as you can flick your finger. When searching, your top search results are loaded in the background as you type so pages appear instantly. And of course, both search and navigation can all be done quickly from the Chrome omnibox.

Simplicity

Chrome for Android is designed from the ground up for mobile devices. We reimagined tabs so they fit just as naturally on a small-screen phone as they do on a larger screen tablet. You can flip or swipe between an unlimited number of tabs using intuitive gestures, as if you’re holding a deck of cards in the palm of your hands, each one a new window to the web.

One of the biggest pains of mobile browsing is selecting the correct link out of several on a small-screen device. Link Preview does away with hunting and pecking for links on a web page by automatically zooming in on links to make selecting the precise one easier.

And as with Chrome on desktop, we built Chrome for Android with privacy in mind from the beginning, including incognito mode for private browsing and fine-grained privacy options (tap menu icon, ‘Settings,’ and then ‘Privacy’).

Sign in

You can now bring your personalized Chrome experience with you to your Android phone or tablet. If you sign in to Chrome on your Android device, you can:

View open tabs: Access the tabs you left open on your computer (also signed into Chrome)—picking up exactly where you left off.

Get smarter suggestions: If you visit a site often on your computer, you'll also get an autocomplete suggestion for it on your mobile device, so you can spend less time typing.

Sync bookmarks: Conveniently access your favorite sites no matter where you are or which device you’re using.

Chrome is now available in Beta from Android Market, in select countries and languages for phones and tablets with Android 4.0, Ice Cream Sandwich. We’re eager to hear your feedback. Finally, we look forward to working closely with the developer community to create a better web on a platform that defines mobile.

Sundar Pichai, SVP, Chrome and Apps

Chrome for Android Beta 1

2012-02-07T10:54:07+00:00

The Chrome team is excited to announce the release of our first beta of Chrome for Android! Based on Chrome 16.0.915.75, Chrome for Android (0.16.4130.199) brings an all new browsing experience to your phone or tablet running Ice Cream Sandwich. More on what’s new can be found on the Chrome for Android page. Developers who want to learn more about working with Chrome for Android can check out the new developer site for working with mobile. More detailed updates are available on the Chrome Blog. If you find a new issue, please let us know by filing a bug.

Srikanth Rajagopalan
Google Chrome

A deeper look at Chrome for Android

2012-02-07T10:35:55+00:00

Today, we introduced Chrome for Android Beta, which brings Chrome’s capabilities to phones and tablets running Android 4.0, Ice Cream Sandwich. This is made possible by a range of innovative features and by building a mobile browser from the ground up that makes full use of the underlying architecture built into Android 4.0.

Chrome for Android brings support for many of the latest HTML5 features to the Android platform. With hardware-accelerated canvas, overflow scroll support, strong HTML5 video support, and new capabilities such as Indexed DB, WebWorkers and Web Sockets, Chrome for Android is a solid platform for developing web content on mobile devices.

In addition to support for the latest web technologies, we hope to make interactive web content super easy to develop. Chrome for Android introduces remote debugging through Chrome Developer Tools to make it simple for developers to debug web sites running live on their mobile devices.

Much of the code for Chrome for Android is already shared with Chromium and over the coming weeks, the Chromium team will be upstreaming many new components developed for Chrome for Android to Chromium, WebKit and other projects.

We’ve got a lot more planned to make Chrome as feature-rich on mobile devices as it is on the desktop. We encourage you to follow any of the ongoing development via the issue tracker or join in on chromium-dev@chromium.org.

Posted by Arnaud Weber, Engineering Manager, Chrome

Chromium 19, Scoped Stylesheets and IDL Refactoring

2012-02-06T21:11:32+00:00

1,368 changes found their way to the repositories last week, 802 for Chromium and 566 for WebKit. Highlights include Chromium 19, an Extension Activity Log page and no more high-latency audio code path.

The branch for Google Chrome 18 has been created, giving Anthony a cause to remind us about Potassium while kicking Chromium’s version 19. Approximately 6,500 Chromium, 4,400 WebKit commits and 300 v8 commits participated in this release, giving a combined total of over 11 thousand changes. Chrome 18 brings six new stable extension APIs, a CSS Selector Profiler, Mutation Observers and many, many more changes.

Work has been started on an Extension Activity Log page which will share information about API calls a certain extension makes, allowing you to keep an eye out on their behavior.

Web Inspector’s Heap Inspector is now able to show a percentage-based representation of memory usage for objects as well. The protocol version has been increased to 1.0, getting an XPath query for an item in the DOM will soon be supported and an experiment for editing styles after a single click has been started. Finally, it’s now also possible to select BlackBerry’s UA strings in the Inspector’s switcher. Work on supporting touch event emulation is progressing.

Support for fixed and percentage-based minimum widths on table elements with table-layout: auto has been implemented, and styling background colors in regions has been re-enabled as well. The preload scanner will now take the base element into account and the disabled attribute on SVG style elements is now supported.

Albeit disabled by default through a compile-time flag, basic functionality of scoped stylesheets has started working per Ronald’s commit. Limitations for selector matching in the <content> element’s select attribute are now being verified, backgrounds inside SVG’s foreignObject element will now be drawn, the Content-Language value (meta-only for now) will influence the document’s locale and fonts and SVG’s getIntersectionList method won’t cause visual distortion anymore.

Through 19 different commits, Kentaro Hara has been doing a great job cleaning up IDL files throughout WebKit .

Other changes which occurred last week:

The Dromaeo bench-mark has been checked in to WebKit and will be used for performance measuring.
The WebKit Mac-port Early Warning System bot is now available for all contributors.
Michael Saboff and Vsevolod Vlasov are now WebKit reviewers, congratulations!
A user’s preferred language may now be taken into account when choosing the right subtitles.
WebKit’s GStreamer-based Web Audio implementation is no longer dependent on FFTW.
It is now possible to build Samsung’s WebKit EFL port with support for WebGL.
Chromium has been taught about Deferred Canvas Rendering, through Skia’s SkDeferredCanvas.
Andreas has killed per-Attribute style declarations and saved another 412 kB of memory.
Antti has been refactoring CSS, splitting WebKit’s internal and external style declarations.
A command line flag has been added to Chromium to enable the Shadow DOM.
The Extension Storage API has been moved back to experimental for Chrome 18.
All Chromium OS bots and builds will now be using the Aura interface.
The high-latency audio code path has been removed from Chromium.
CSS Filters have been enabled for WebKit’s Windows port.

And that’s all again!

Revocation checking and Chrome's CRL

2012-02-05T08:00:00+00:00

When a browser connects to an HTTPS site it receives signed certificates which allow it to verify that it's really connecting to the domain that it should be connecting to. In those certificates are pointers to services, run by the Certificate Authorities (CAs) that issued the certificate, that allow the browser to get up-to-date information.

All the major desktop browsers will contact those services to inquire whether the certificate has been revoked. There are two protocols/formats involved: OCSP and CRL, although the differences aren't relevant here. I mention them only so that readers can recognise the terms in other discussions.

The problem with these checks, that we call online revocation checks, is that the browser can't be sure that it can reach the CA's servers. There are lots of cases where it's not possible: captive portals are one. A captive portal frequently requires you to sign in on an HTTPS site, but blocks traffic to all other sites, including the CA's OCSP servers.

If browsers were to insist on talking to the CA before accepting a certificate, all these cases would stop working. There's also the concern that the CA may experience downtime and it's bad engineering practice to build in single points of failure.

Therefore online revocation checks which result in a network error are effectively ignored (this is called “soft-fail”). I've previously documented the resulting behaviour of several browsers.

But an attacker who can intercept HTTPS connections can also make online revocation checks appear to fail and so bypass the revocation checks! In cases where the attacker can only intercept a subset of a victim's traffic (i.e. the SSL traffic but not the revocation checks), the attacker is likely to be a backbone provider capable of DNS or BGP poisoning to block the revocation checks too.

If the attacker is close to the server then online revocation checks can be effective, but an attacker close to the server can get certificates issued from many CAs and deploy different certificates as needed. In short, even revocation checks don't stop this from being a real mess.

So soft-fail revocation checks are like a seat-belt that snaps when you crash. Even though it works 99% of the time, it's worthless because it only works when you don't need it.

While the benefits of online revocation checking are hard to find, the costs are clear: online revocation checks are slow and compromise privacy. The median time for a successful OCSP check is ~300ms and the mean is nearly a second. This delays page loading and discourages sites from using HTTPS. They are also a privacy concern because the CA learns the IP address of users and which sites they're visiting.

On this basis, we're currently planning on disabling online revocation checks in a future version of Chrome. (There is a class of higher-security certificate, called an EV certificate, where we haven't made a decision about what to do yet.)

Pushing a revocation list

Our current method of revoking certificates in response to major incidents is to push a software update. Microsoft, Opera and Firefox also push software updates for serious incidents rather than rely on online revocation checks. But our software updates require that users restart their browser before they take effect, so we would like a lighter weight method of revoking certificates.

So Chrome will start to reuse its existing update mechanism to maintain a list of revoked certificates, as first proposed to the CA/Browser Forum by Chris Bailey and Kirk Hall of AffirmTrust last April. This list can take effect without having to restart the browser.

An attacker can still block updates, but they have to be able to maintain the block constantly, from the time of revocation, to prevent the update. This is much harder than blocking an online revocation check, where the attacker only has to block the checks during the attack.

Since we're pushing a list of revoked certificates anyway, we would like to invite CAs to contribute their revoked certificates (CRLs) to the list. We have to be mindful of size, but the vast majority of revocations happen for purely administrative reasons and can be excluded. So, if we can get the details of the more important revocations, we can improve user security. Our criteria for including revocations are:

The CRL must be crawlable: we must be able to fetch it over HTTP and robots.txt must not exclude GoogleBot.
The CRL must be valid by RFC 5280 and none of the serial numbers may be negative.
CRLs that cover EV certificates are taken in preference, while still considering point (4).
CRLs that include revocation reasons can be filtered to take less space and are preferred.

For the curious, there is a tool for fetching and parsing Chrome's list of revoked certificates at https://github.com/agl/crlset-tools.

German Federal Office of Information Security recommends Chrome

2012-02-03T09:19:57+00:00

Today the BSI, Germany’s Federal Office for Information Security, released a best practice guide for Windows users as part of their overall guidelines and recommendations for Cyber Security. Security has always been a core focus of Chrome, so we’re particularly honored to see several of its security benefits recognized in the report:

The browser is the central component for using any online service on the Web and therefore is the most critical attack surface for cyber attacks. Therefore, if possible, you should use a browser with sandbox technology. The browser that currently most consistently implements this protection is Google Chrome (https://www.google.com/chrome). Comparable mechanisms implemented in other browsers are either weaker, or non-existent. By using Google Chrome, in addition to the other mechanisms we mentioned, you can significantly reduce the risk of a successful IT attack.

In addition to Chrome’s sandbox, the guide also highlights the importance of Chrome’s auto-update feature:

Equally positive is the auto-update functionality of Google Chrome, which includes a bundled version of the Adobe Flash Player. By bundling it with Chrome, the Adobe Flash Player will also always be kept up to date.

On the eve of Safer Internet Day, security on the web still faces a variety of challenges. We hope our efforts to improve the security and privacy of our users continue to help make the web a better place.

Posted by Dr. Wieland Holfelder, German Extraordinaire, and Travis McCoy, Security Aficionado

Dev Channel Update

2012-02-02T17:55:13+00:00

The Dev channel has been updated to 18.0.1025.3 for Windows, Mac, Linux and Chrome Frame. This build contains following stability and bug fixes:

Fixed URL handling of settings page. [Issue: 111900]
Fixed crash when unpacking extension. [Issue: 112301]
Fixed the case where the utility process crashes after all plugins have been loaded. [Issue: 111935]

Dev Channel Update

2012-01-31T16:53:04+00:00

The Dev channel has been updated to 18.0.1025.1 for Windows, Mac, Linux and Chrome Frame. This build contains the following updates:

All

Updated V8 - 3.8.9.0
Moved the ‘privacy’ extension API out of experimental (Issue: 88030)

Mac

Fixed bookmarks menu being empty after switching profile. (Issue: 111034)

Perform Lion navigation gestures in the right window (Issues: 102541, 110655)

Fixed momentum scrolling that’s broken in iframes. (Issue: 112085)

Fixed Devtools closing in wrong tab when clicking close after resize. (Issue: 111206)

Known Issues

Settings revamp is still a work-in-progress. Please file issues at crbug.com.

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

Dharani Govindan
Google Chrome

All About Safe Browsing

2012-01-31T09:24:17+00:00

While the web is a virtual treasure trove of great content, it’s also used by bad guys to steal personal information. One of Chrome’s most advanced security features, Safe Browsing, helps protect against the three most common threats on the web: phishing, drive-by malware, and harmful downloads. We recently announced some new enhancements to Safe Browsing, so we thought we’d offer an inside look into how it works.

Safe Browsing downloads a continuously-updated list of known phishing and malware websites, generated by an automated analysis of our entire web index. Each page you visit, and each resource (such as pictures and scripts) on the page, are checked against these lists. This is done in a way that does not reveal the websites you visit, and is described in more detail in our video on Safe Browsing. If Chrome detects that you’ve visited a page on the list, it warns you with a large red page that helps you get back to safety.

Of course, this only helps for dangerous content that Google already knows about. To provide better protection, Safe Browsing has two additional mechanisms that can detect phishing attacks and harmful downloads the system has never encountered before.

Phishing attacks are often only active for a few short hours, so it’s especially important to detect new attacks as they happen. Chrome now analyzes properties of each page you visit to determine the likelihood of it being a phishing page. This is done locally on your computer, and doesn’t share the websites you visit with Google. Only if the page looks sufficiently suspicious will Chrome send the URL of that page back to Google for further analysis, and show a warning as appropriate.

Malicious downloads are especially tricky to detect since they’re often posted on rapidly changing URLs and are even “re-packed” to fool anti-virus programs. Chrome helps counter this behavior by checking executable downloads against a list of known good files and publishers. If a file isn’t from a known source, Chrome sends the URL and IP of the host and other meta data, such as the file’s hash and binary size, to Google. The file is automatically classified using machine learning analysis and the reputation and trustworthiness of files previously seen from the same publisher and website. Google then sends the results back to Chrome, which warns you if you’re at risk.

It’s important to note that any time Safe Browsing sends data back to Google, such as information about a suspected phishing page or malicious file, the information is only used to flag malicious activity and is never used anywhere else at Google. After two weeks, any associated information, such as your IP address, is stripped, and only the URL itself is retained. If you’d rather not send any information to Safe Browsing, you can also turn these features off.

This multi-pronged protection combines to make you much safer against the most prevalent attacks on the web while carefully guarding your privacy. We’ve always believed in making the web a safer place for everyone, so we also make the Safe Browsing API available for free to other browsers and websites.

Safe surfing!

Posted by Niels Provos, Software Engineer, and Ian Fette, Product Manager

Shadow DOM, Pointer Lock and a new CSS Lexer

2012-01-30T18:13:14+00:00

929 changes landed at Chromium’s repository last week, whereas WebKit’s received 626, totaling up to 1,555. Highlights include quite some progress on implementing the Shadow DOM and the Pointer Lock API.

Web Inspector’s Timeline Panel has been extended with three graphs, all hidden behind the Experimental Settings option, showing information about objects and events in the DOM. Hovering over a function in the Script Panel may now show an overlay with general information and it’s source-code and elements within iframes are selectable again.

The Flexible Box module implementation has been taught about distributed packing and now supports scrollbars for overflowing content, also taking the flex direction into account. Furthermore, floated pseudo-elements within table captions will now be positioned correctly.

In order to verify whether ES.next’s let keyword will be compatible with websites, Apple has reserved the word from normal usage in JavaScriptCore. Support for Uint8ClampedArray has landed for both V8 as JSC, values for the dropzone attribute will be normalized and various issues with radio-button groups have been fixed.

In terms of the Shadow DOM, registering of scoped stylesheets with the scoped element has been implemented and an initial version of the <content> element is now available as well. Following an API change and the actual interface, Vincent Scheib’ Pointer Lock API has made it into Chrome Canary as well.

Other changes which occurred last week:

Zoltan Herczeg wrote a custom CSS Lexer for WebKit, doubling lexing performance!
The parsing stage of calc() has landed in WebKit, following several new tests.
The JavaScriptGlue folder in WebKit’s Source/ directory has been removed.
WebKit’s Qt port now features tap feedback respecting the tap-highlight-color property.
Parsing of the Content-Disposition HTTP header has been improved, aligning more closely to RFC 6266.
Ryosuke is working on bringing performance tests to WebKit, to be visualized using Mozilla’s Graph server.
Elements without attributes are slightly smaller, resulting in another ~0.23% memory improvement.
Styles won’t be updated synchronously anymore after running a script.
An about:flags entry has been added for enabling the Media Stream API, including getUserMedia.
Another flag has been added to disable the GPU for accelerated rendering, falling back to software mode.
A debug page for the Omnibox has been added as chrome://omnibox/.
Storage Quotas are now available through the Extension Storage API, as the getBytesInUse method.
An Extension API event informing about brightness changes has been implemented for Chromium OS.
The Privacy Extension API has been moved out of the experimental namespace, as has the Storage API.

And that’ll be all again, thanks for reading!

Beta Channel Update

2012-01-30T13:46:52+00:00

The Beta channel has been updated to 17.0.963.46 for all platforms including Chromebooks (Platform versions: 1412.150). This update fixes a number of stability and UI issues. For Chromebook users, it also includes a new version of Pepper Flash. Full details about what changes are in this version of Chrome are available in the SVN revision log. Interested in switching release channels? Find out how on Chrome / Chromebooks. If you find a new issue, please let us know by filing a Chrome or Chrome OS bug.

Jason Kersey
Google Chrome

Translating JavaScript to Dart

2012-01-30T12:07:23+00:00

Cross posted to: dartlang.org and the Google Code Blog

It took approximately 2000 years for the original Rosetta Stone to be discovered, which helped translate the Egyptian Hieroglyphs. We couldn’t wait that long to bridge the Dart and JavaScript worlds, so today we are releasing the JavaScript to Dart Synonym app.

Like most web developers, we are familiar, comfortable, and productive with JavaScript. We were curious about Dart, and thanks to a recent Dart hackathon, we had the chance to play with the language and libraries. The problem was, as JavaScript developers, we didn’t know how to map common JavaScript idioms to Dart. Hence the idea for this synonym app was born.

We started with the basics that every JavaScript and jQuery developer knows: variables, arrays, functions, classes, DOM manipulation, and many more. Then, with the help of the Dart team, we recorded the corresponding Dart versions of each idiom. To practice what we learned, we wrote this app with Dart.

We hope our app that maps between JavaScript and Dart eases your introduction to Dart and gives you a sense of where the project is going. We know the team is eager to hear your feedback. Don’t hesitate to join the conversation or file a new issue for either Dart or the Synonym app. And remember, Dart isn’t set in stone, so your feedback counts.

Posted by Aaron Wheeler and Marcin Wichary

Extracting Mozilla's Root Certificates

2012-01-30T08:00:00+00:00

When people need a list of root certificates, they often turn to Mozilla's. However, Mozilla doesn't produce a nice list of PEM encoded certificates. Rather, they keep them in a form which is convenient for NSS to build from: https://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt?raw=1.

Several people have written quick scripts to try and convert this into PEM format, but they often miss something critical: some certificates are explicitly distrusted. These include the DigiNotar certificates and the misissued COMODO certificates. If you don't parse the trust records from the NSS data file, then you end up trusting these too! There's at least one, major example of this that I know of.

(Even with a correct root file, unless you do hard fail revocation checking you're still vulnerable to the misissued COMODO certificates.)

So, at the prodding of Denton Gentry, I've open-sourced a tool for converting NSS's file to PEM format: extract-nss-root-certs. (At the time of writing it requires a 6g built from the weekly or current tree (hg -r weekly), not the release tree. A few of the APIs have changed since the last Go release was done. This will be resolved when Go 1.0 is released.)

Dev Channel Update for Chromebooks

2012-01-27T14:18:48+00:00

The Dev channel has been updated to 18.0.1017.3 (Platform versions: 1625.0.0) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48).

This build contains a number of performance, stability and security improvements. Additional changes:

Fixes to login problems that users may have encountered on machines that were shipped with versions R11 and earlier.
Updated Pepper flash version.

Known issues:

25557 & 25559 - Hangouts will not display video of yourself or participants on Chromebooks. Audio does work, and other Hangout participants will be able to see you if video is enabled. This problem does not affect GTalk Video.
25509 - Occasionally when switching tabs, the screen will not redraw the content to the new tab. Workaround: Closing all tabs or restarting the machine resolves the issue.

Vsevolod Vlasov is a WebKit Reviewer!

2012-01-27T13:08:02+00:00

Vsevolod Vlasov has been a major contributor to the recent improvements to the Web Inspector. Please join me in congratulating Vsevolod on his new role as a WebKit reviewer!

Beta Channel Update for Chromebooks

2012-01-26T13:44:49+00:00

The Beta channel has been updated to 17.0.963.43 (Platform versions: 1412.142) for Chromebooks (Samsung Series 5 , and Cr-48).

Highlights:

This update fixes a number of stability and UI issues.
Introduces new Verizon activation and top-up portal featuring many user-requested improvements:

Enables recurring billing as the default for pre-paid monthly plans
Greatly simplifies the Verizon activation and top-up process
Allows purchase of additional data prior to current bundle expiration
Eliminates credit card requirement for free 100MB plan

Making the web speedier and safer with SPDY

2012-01-26T11:30:00+00:00

In the two years since we announced SPDY, we’ve been working with the web community on evolving the spec and getting SPDY deployed on the Web.

Chrome, Android Honeycomb devices, and Google's servers have been speaking SPDY for some time, bringing important benefits to users. For example, thanks to SPDY, a significant percentage of Chrome users saw a decrease in search latency when we launched SSL-search. Given that Google search results are some of the most highly optimized pages on the internet, this was a surprising and welcome result.

We’ve also seen widespread community uptake and participation. Recently, Firefox has added SPDY support, which means that soon half of the browsers in use will support SPDY. On the server front, nginx has announced plans to implement SPDY, and we're actively working on a full featured mod-spdy for Apache. In addition, Strangeloop, Amazon, and Cotendo have all announced that they’ve been using SPDY.

Given SPDY's rapid adoption rate, we’re working hard on acceptance tests to help validate new implementations. Our best practices document can also help website operators make their sites as speedy as possible.

With the help of Mozilla and other contributors, we’re pushing hard to finalize and implement SPDY draft-3 in early 2012, as standardization discussions for SPDY will start at the next meeting of the IETF.

We look forward to working even closer with the community to improve SPDY and make the Web faster!

To learn more about SPDY, see the link to a Tech Talk here, with slides here.

Posted by Roberto Peon and Will Chan, Software Engineers

Beta Channel Update

2012-01-25T16:47:55+00:00

The Beta channel has been updated to 17.0.963.44 for all platforms other than Chrome OS. This update fixes a number of stability and UI issues. Full details about what changes are in this build are available in the SVN revision log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug.

Jason Kersey
Google Chrome

Making form-filling faster, easier and smarter

2012-01-25T10:37:06+00:00

One of my favorite features of Chrome got a boost earlier today, as we announced support for an experimental new “autocomplete type” attribute for form fields. The new attribute will allow web developers to unambiguously label text and select fields with common data types such as ‘full-name’ or ‘street-address’ and guarantee that their site’s forms work correctly with Chrome Autofill and other form-filling providers.

We’ve been working on this design in collaboration with several other autofill vendors. Like any early stage proposal we expect this will change and evolve as the web standards community provides feedback, but we believe this will serve as a good starting point for the discussion on how to best support autofillable forms in the HTML5 spec. For now, this new attribute is implemented in Chrome as x-autocompletetype to indicate that this is still experimental and not yet a standard, similar to the webkitspeech attribute we released last summer.

For more information, you can read the full text of the proposed specification, ask questions on the Webmaster help forum, or you can share your feedback in the standardization discussion!

Posted by Ilya Sherman, Software Engineer

Bringing Chromebooks to every classroom

2012-01-25T08:40:31+00:00

Cross-posted from the Google Enterprise Blog.

Editor's note: We’re posting this electronic communication from sunny Orlando, where we’re chatting with schools at the annual FETC ed-tech conference. We wanted to share highlights from our keynote this morning, which featured a panel moderated by Tom Vander Ark, author of Getting Smart: How Digital Learning is Changing the World. You can watch a replay of the keynote on YouTube in a few hours. If you’re in town, come visit us at our booth #1101 - we’d love to say hi!

When we first conceived of Chromebooks, we were focused on providing a device that brought you to the web in the fastest, simplest and securest way possible. What we didn't realize at the time was that this device would be so welcome and popular in classrooms! Many schools are eager to improve access to the web and technology for students and are planning to provide each student with their own device – a concept known as "1-to-1" computing. We've heard from our customers that they choose Chromebooks for 1-to-1 because the simplicity of the web takes away the hassle for teachers, students and administrators.

During our keynote at FETC this morning, we had the opportunity to share some exciting news: hundreds of schools in 41 states across the U.S. are using one or more classroom sets of Chromebooks today. As a highlight, three new school districts in Iowa, Illinois and South Carolina are going 1-to-1 – that is, one Chromebook each for nearly 27,000 students.

Council Bluffs Community School District in Iowa is planning a Chromebook 1:1 Initiative for all 2,800 students in their two high schools and will use an additional 1500 Chomebooks in their two middle schools

Leyden Community High School District in Illinois will roll out devices to 3,500 students in their two high schools

Richland School District Two in South Carolina is going 1-to-1 with a total of 19,000 students

It's great to see this positive momentum for Chromebooks in classrooms. It's similar to where we were about five years ago when Google Apps was just getting off the ground. At that time, educational institutions were the most interested and it was inspiring to hear the different ways schools and districts had begun using Gmail, Calendar and Docs. At FETC we’ve been similarly excited to see how teachers have formed communities around professional development for Chromebooks, districts all across the US are piloting Chromebooks in their classrooms, and more and more reach out to us to learn about Chromebooks for Education every day. We believe Chromebooks and the web have the ability to facilitate learning in a powerful way, and we’re committed to helping schools recognize their goals to go 1-to-1.

But enough words from us. We’d like to close with thoughts from representatives of each of these school districts.

“From my perspective, Chromebooks couldn’t get any simpler; setting up this many laptops would have typically taken our team at least 3 months. And from the instructional side, we are teaching content not technology, and Chromebooks simply support teachers in what they do best while giving students the resources they need to be productive citizens. As just one example the quality of work that students turn in has improved literally overnight - from incomplete sentences to full paragraphs, in some cases - because they are much more engaged and participating readily in class.”

David Fringer, executive director, information systems at Council Bluffs Community school district, Iowa

“When we started on our digital evolution path we were looking for just the right tool - one that is invisible and gets out of the way to allow students and teachers to focus on instruction. With Chromebooks our students are publishing, producing and sharing with each other, and best of all, we don’t have to assign students a particular device number. Any student can use any device because all their work is saved online - for that matter they could access their work from home while logged in from the Chrome browser.”

Bryan Weinert, director of technology at Leyden school district, Illinois

Student at East Leyden high school selects a Chromebook from the charging cart. With Chromebooks, students can work on any device in any class period and access their work from anywhere - including from the Chrome browser installed on a home computer.

“Chromebooks make our 1-to-1 computing dream a reality. Teachers don't need to add ‘help desk’ to their job description, and they save valuable class time knowing they can instruct students to close the Chromebooks to stay on task and they won't have to wait when it’s time to open them again. Furthermore, we’ve seen that any behavior issues become an absolute non-issue because the technology is so compelling.”

Tom Cranmer, executive director of information technology, Richland School District Two, South Carolina

Fifth grade student teaches a younger student how to use a Chromebook in the Chrome Buddy project in Tim Swick's classroom at Pontiac Elementary School in Richland School District Two.

Learn more about Chromebooks for Education on our website, and join us for the Chromebook Classroom webinar series, Wednesdays at 9AM PT/12PM ET.

Posted by Rajen Sheth, Group Product Manager for Chromebooks

Dev Channel Update

2012-01-24T17:52:46+00:00

The Dev channel has been updated to 18.0.1017.2 for Windows, Mac, Linux and Chrome Frame. This build contains the following updates:

All

Updated V8 - 3.8.7.1
Enable linear scaling for Chrome Remote Desktop’s scale-to-fit feature. (issue 93451)
Fixed popup windows issue (Issue: 106967)
Fixed crashes in extension binding (Issue: 110694)
When Strict Transport Security mandates that HTTPS certificate errors must be fatal, add a string telling the user why. (Issue: 110191)

Mac

Fixed flashing window while deleting profile (Issue: 108801)

Stable Channel Update

2012-01-24T10:42:56+00:00

The Stable channel has been updated to 16.0.912.77 for Windows, Mac, Linux and Chrome Frame

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.

[$1000] [106484] High CVE-2011-3924: Use-after-free in DOM selections. Credit to Arthur Gerkis.

[$3133.7] [107182] Critical CVE-2011-3925: Use-after-free in Safe Browsing navigation. Credit to Chamal de Silva. *

[108461] High CVE-2011-3928: Use-after-free in DOM handling. Credit to wushi of team509 reported through ZDI (ZDI-CAN-1415).

[$1000] [108605] High CVE-2011-3927: Uninitialized value in Skia. Credit to miaubiz.

[$1000] [109556] High CVE-2011-3926: Heap-buffer-overflow in tree builder. Credit to Arthur Gerkis.

The bugs 106484, 107182, 108461, and 109556 were detected using AddressSanitizer.
* Bug 107182 was fixed in 16.0.912.75 but accidentally excluded from the release notes.

Full details about what changes have been made in this release are available in the SVN revisions log. Interested in switching to another channel? Find out how. If you find a new issue, please let us know by filing a bug.

Anthony Laforge
Google Chrome

Content Shell, Shadow DOM and Emulating Screen Sizes

2012-01-23T18:14:31+00:00

Last week brought 563 new commits in WebKit’s repository and 709 new commits to Chromium’s, totalling up to 1,272 changes. Highlights include a content shell for Chromium and work on emulating screen sizes.

Chromium’s content shell for Linux-based systems was announced on the chromium-dev mailing list on Friday, sharing the news that it’s now usable for day-to-day WebKit development. It uses Chromium’s content module but leaves out other parts of the browser, so it’ll be significantly faster to compile and run.

For free-flow HTML editing in the Resources Panel of Web Inspector, revisions will now be tracked. Unsafe cross-origin requests will now show a stack trace in the console, making them easier to track down and content in iframes won’t appear to be in the same document anymore when using the DOM Viewer. Finally, a screen-size emulation back-end has been implemented, which will eventually allow you to emulate mobile device screens!

The -webkit-cross-fade will now report the intrinsic size of the background, fixing rendering when the background-size property is being used. Baseline grid alignment has been implemented, as have the text-overflow property for input fields and parsing for the custom() function of CSS Shaders. Painting background colors for regions has been re-enabled, and regions will now be exposed to the DOM.

WebKit’s Device Orientation implementation has been updated with the absolute property, which indicates whether the angles in the event are absolute. The abort() method for Application Cache has been added, as has a constructor for MediaStream accepting a collection of MediaStreamTracks. A window’s innerWidth and innerHeight properties won’t be affected by page scales anymore and drop and dragend events will now be issued for contentEditable elements.

Finally, the first significant patch in exposing the Shadow DOM to JavaScript has landed in WebKit! Minor as it is right now, it’ll pave the path to implementing the rest of the specification.

Other changes which occurred last week:

Hardware accelerated brightness and contrast filters have been implemented for Safari.
IndexedDB has also been made supplemental and moved out of DOMWindow.cpp.
Values of the Access-Control-Request-Headers header will now be send in lowercase.
Another 0.8 MB of memory will be saved when viewing some random version of the HTML Specification.
A special honorable mention for this immediately obvious commit message.
Software-based 3D rendering can be disabled through about:flags now.
Documentation of several Web Inspector-related Extension APIs is no longer experimental either.
The experimental Settings Extension API now understands the unlimitedStorage permission as well.
The headers and body of HTTP requests will now be merged if the total length is <1400 characters.
The Network Action Predictor (chrome://network-action-predictor) now features probability filtering.

Finally, be sure to take a look at HTML5 Please, a new website sharing recommendations about which features of the Web Platform can be used today!