Last.fm Free Music Player Google Chrome Extension

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

Why is Google supporting WebM for the HTML tag?

As part of their effort to speed up release cycles, Google no longer likes to acknowledge in a big way when they update Chrome. They’re simply doing it too often for it to mean much. But today they’ve taken a bit of time to acknowledge an update to both Chrome and Chrome OS, in part because they were able to quash a big bug.

Specifically, Chrome and Chrome OS were updated to versions 8.0.552.237 and 8.0.552.334, respectively. That itself isn’t huge news as both were already on version 8 — but again, the versions simply don’t mean much anymore. Instead, the bigger news is that Google gave out the first “Elite” Chromium security reward.

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

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

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

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

We’re happy to announce that WebGL is now on by default in Google Chrome’s beta channel, with some shiny new demos to show off what the technology can do.

WebGL is a 3D graphics API for JavaScript that developers can use to create fully 3D web apps. It is based on the OpenGL ES 2.0 API, which should be familiar to many 3D graphics developers. Google, Mozilla, Apple, Opera and graphics hardware vendors have been working together to standardize WebGL for over a year now, and since the spec is just about final at this point, we wanted to get our implementation out there for feedback.

While you may not find much WebGL content on the web, we expect developers to quickly create a lot of content given the power and familiarity of the API. To inspire developers and give users a taste of the kind of apps they can expect in the near future, we’ve worked with a few talented teams to build a few more 3D web apps:

Body Browser, a human anatomy explorer built by a team at Google as a 20% project

Nine Point Five, a 3D earthquake map by Dean McNamee

Music Visualizer, a jukebox that synchronizes 3D graphics to the beat of the music by Jacob Seidelin

You can find these and other demos in the new Chrome Experiments Gallery for WebGL demos. Now that WebGL is enabled in the beta channel, the Chrome Experiments team is looking for your cool WebGL app submissions to show off this slick technology, so don’t forget to submit your cool 3D apps!

Since we launched the Chromium project over two years ago, we’ve been hearing a lot of feedback from IT administrators who want to manage and configure Google Chrome. Of course, we were eager to do what we could to help them get Chrome deployed inside their organizations.

Today, after talking directly to administrators and testing the features extensively with other organizations, we believe the first set of features is ready for prime-time. Both Chrome and Chromium are now manageable through Group Policy objects on Windows, plist/MCX configuration on Mac, and special JSON configuration files on Linux. We polished up the NTLM and Kerberos protocol support, and created a list of supported policies and administrative templates to help administrators deploy. For users needing access to older web applications not yet qualified for Chrome, we also developed Chrome Frame, an Internet Explorer (TM) plug-in that provides Chrome-quality rendering for the broader Web, while defaulting to host rendering for any web applications that still require IE.

No feature is really useful to an administrator without great documentation, so we wrote articles to help admins in the configuration and deployment of both Google Chrome and Chromium. We also documented answers to the top questions testers encountered when deploying.

Even though the first set of features is done, we still have a lot more we’d like to do. We have some interesting ideas that we’re working on, including more policies to manage everything in the content settings and authentication protocols, and interesting new ways to deploy policy cross-platform. But we could use your help: please try out the new features by checking out the documentation, downloading the MSI installer, and filing bugs. And let your administrator know to give it a try and let us know what they think.

It should be pretty clear by now that Google is taking location very seriously. The original launch of Latitude in early 2009 was just a first step. Now they have robust APIs, Google Places, and key executive Marissa Mayer is now in charge of these and various related projects. And earlier today they finally rolled out a Latitude iPhone app. But if a fairly small tweak to Chrome is any indication, Google means to go deeper still.

Chrome Developer Tools' Scripts panel provides a graphical JavaScript debugger and allows you to set breakpoints in the JavaScript source code. However, setting breakpoints in the source code does not always work well, especially when the application is large and you are not familiar with the entire code base. To better support this use case, we are introducing a new set of breakpoints that allow you to break on UI and network events.

Suppose you need to find the piece of code that modifies a specific node in a document. Right-click on that node in the Elements panel and select the appropriate “Break on...” context menu option and you are all set. The debugger will pause JavaScript execution right before the node gets modified next time.

To learn more about DOM breakpoints and other new kinds of breakpoints, visit our Breakpoints Tutorial page.

It’s hard to believe, but it’s already been a full year since we launched the Google Chrome extensions gallery.

It’s been a busy twelve months:

• The gallery has grown to over 8,500 extensions and 1,500 themes.
• A third of Chrome users have at least one extension installed.
• Over 70 million extensions and themes have been installed.

On the client side, we added features like:

• New APIs for things like context menus, history, and cookies.
• Integration between extensions and HTML5 features like notifications and geolocation.
• Extension sync, so your favorite extensions are always with you.
• Native support for Greasemonkey user scripts.

Looking forward, we’re very excited about the Chrome Web Store, where developers will be able to easily sell their apps, extensions, and themes.

And we’re not going to slow down on the features, either. The next Chrome release will add API support for the omnibox and pinned tabs. Beyond that, we’re hard at work on popular requests like network interception and download management APIs, as well as new experimental APIs for sidebars and development tools.

Thanks for all your support over the last year, from bug reports to testing new APIs. It’s been a bit frantic at times, but mostly it’s been fun.

With all the Chrome OS and Chrome Web Store hoopla today, a post over at the Chromium blog went mostly unnoticed -- and it's definitely noteworthy. Freshly baked in the Chromium snapshot builds and Google Chrome Canary is Crankshaft, an enhancement to Chrome's V8 JavaScript engine that has yielded some impressive gains.

Crankshaft is made up of four components:

• a runtime profiler for identifying code that uses a significant number of CPU cycles
• a base compiler for generating code more quickly
• an optimizing compiler which re-compiles code pinpointed by the profiler
• deoptimization mechanism that allows Crankshaft to recover from overly-optimistic code optimizations

Crankshaft offers improvements in both startup time and maximum performance, with Google noting gains of up to 12% on JavaScript-heavy pages. On Google's own V8 benchmark, Crankshaft helps Chrome post scores which are almost 50% higher than previous versions with V8 alone.

...And for those of you wondering when Chrome was going to hit version ten, you've got your answer. It's already happened to the Canary build -- so hit your wrench menu > About Google Chrome and restart to update yourself to Chrome X! There's not much new that you'll notice right off the bat, with the exception of a selectable Instant option and experimental geolocation features in about:flags.

Google Chrome 8.0 stable is finally released for Windows, Mac and Linux. The latest version, Google Chrome 8.0.552.215, include a built-in PDF viewer among many other stability related enhancements and major security fixes.

What's New in Google Chrome 8.0?

Since this past March, we’ve been working closely with Adobe to allow Flash Player to take advantage of new sandboxing technology in Chrome, extending the work we’ve already done with sandboxing for HTML rendering and JavaScript execution. This week, we’re excited to roll out the initial Flash Player sandbox for our dev channel users on Windows XP, Vista and 7.

This initial Flash Player sandbox is an important milestone in making Chrome even safer. In particular, users of Windows XP will see a major security benefit, as Chrome is currently the only browser on the XP platform that runs Flash Player in a sandbox. This first iteration of Chrome’s Flash Player sandbox for all Windows platforms uses a modified version of Chrome’s existing sandbox technology that protects certain sensitive resources from being accessed by malicious code, while allowing applications to use less sensitive ones. This implementation is a significant first step in further reducing the potential attack surface of the browser and protecting users against common malware.

While we’ve laid a tremendous amount of groundwork in this initial sandbox, there’s still more work to be done. We’re working to improve protection against additional attack vectors, and will be using this initial effort to provide fully sandboxed implementations of the Flash Player on all platforms.

We’ll be posting updates as we continue working with Adobe to add new security improvements to the Flash Player sandbox. For those of you on the dev channel for Windows, you’ll be automatically updated soon, and we look forward to your feedback as you test it out. If you prefer to disable this initial sandbox in your Chrome dev experience, add --disable-flash-sandbox to the command line.

Google Chrome can already create application shortcuts for your favorite sites via the wrench menu. The option had disappeared for a while, but made its return earlier this year. Adding Gmail to your taskbar is as simple as loading it in a tab, clicking the wrench, choosing tools and then clicking create application shortcut.

Recently, Chromium added that same functionality to Chrome Web apps. If you've got any apps installed, you can right click its icon on your new tab page and choose create shortcut. A menu like the one pictured above will appear, and you can then pin your Chrome Web app the Windows 7 taskbar or slap a shortcut on your desktop or start menu.

This is currently only available in Chromium, but expect to see Web app shortcuts make their way to the Canary and Dev builds in short order. Google is making a push to get the Chrome Web Store launched, and polished app support in Chrome will need to be in place prior to, well, whenever that happens.

This is part of a series of blog posts that provide tips and tricks on how to create better web apps as well as insights behind the technology of the Chrome Web Store - Ed.

Web development sure got fun recently, right? Local storage, notifications, new form controls, geolocation, inline multimedia... the list goes on and on. These new capabilities can help web developers build powerful new features in their apps.

However, many of these new additions to the web platform are not allowed to web pages by default. For example, to protect a user’s privacy, browsers do not allow web pages to use the geolocation API to access a user’s location unless they prompt the user. Browsers show these prompts each time a web page tries to use a potentially invasive or unsafe capability:

But these prompts can be quite annoying, especially when one web page asks for several of them. And some of these privileges are relatively obscure or incomprehensible to the user. As a result they end up being ignored or scare users from allowing a particular functionality. Most people don’t know what a “clipboard” is, so asking them about access to it is not that informative or helpful.

Now in the Chrome Web Store, developers can create “apps” that group together multiple privilege requests for a single site. Apps have a lightweight installation step that displays the privileges the app requests all together. Once an app is installed, it can use the privileges it requested during the installation process without any further nagging.

Some privileges are relatively low-risk, so we infer permission to use them from the act of installing the application. An example of this is the notifications API. The only reason it isn’t allowed to normal web sites by default is that it could be used annoyingly. When a user installs an app, we interpret that as a sign of at least some trust, and allow that application to use the Notifications API without additional prompting. If users do not like the notifications that the application generates, they can either disable them in the app’s notification UI or they can simply uninstall the app.

In this first version of apps for the Chrome Web Store, we support permission request declarations for the geolocation, notifications, and unlimited storage privileges. Over time we’ll be adding even more.

To learn more about how to build apps for the Chrome Web Store, visit the developer documentation at code.google.com/chrome/webstore.

We have discovered compatibility issues between Google Chrome and Microsoft’s Enhanced Mitigation Experience Toolkit (EMET). EMET is used to deploy and configure security mitigation technologies, often for legacy software. However, because Chrome already uses many of the same techniques (and more), EMET does not provide any additional protection for Chrome. In fact, the current version of EMET interferes with Chrome’s security and prevents Chrome from updating.

We are working closely with Microsoft on a solution to these issues. In the meantime, we advise users and enterprises not to attempt to configure EMET to work with Chrome.

Google Chrome 9 has arrived for Dev channel users, and while the list of changes in 9.0.570.0 is a lengthy one you're not going see any major differences. Not just yet, anyway.

A number of the updates lay the groundwork for features that will be "coming soon." There's been a lot of work focused around Cloud Print, for example. Google Instant integration has also been tweaked, and a number of small UI issues have been touched up. The extension system received a lot of attention, with tweaks being made to both the filesystem and sidebar APIs.

Among the more significant additions are things like the internal DNS resolver (which arrived in Chromium recently) and password sync. Google's V8 JavaScript engine has been bumped to v2.5, and don't forget about Chrome's hardware acceleration features -- they haven't been turned on by default just yet, but work continues. They are on the roadmap for the final release of Chrome 9.

Today we are kicking off a series of blog posts that provide tips and tricks on how to create better web apps as well as insights behind the technology of the Chrome Web Store - Ed.

Looking at building a web app for the Chrome Web Store? The browser landscape has changed a lot recently and user expectations about the quality and polish level of apps are extremely high thanks in part to the success of highly polished mobile apps. Can you meet these high expectations with a webapp?

Fortunately, you now have a lot more power and flexibility with the user interface thanks to the power of HTML5, CSS3, and other new web technologies. It’s now possible to make a web app that is every bit as slick and polished as the best desktop or phone app, while still maintaining the flexibility and portability of the web. For example, using CSS3 transitions and animations, you can make actions in your app feel much more interactive. You can use CSS3’s support for gradients, reflections and rounded corners to create scalable interfaces that look as if they were built using hand-crafted images. And with the rise of GPU-accelerated graphics, you’re now able to create compelling 3D experiences.

However, creating great user experiences is about more than sizzle and polish. Another important factor is focus. Ideally, an app should accomplish a single task well with a minimal amount of distractions. Be judicious with your use of links and ads that could take users away from the task at hand. When the user launches your app, they’re trying to accomplish something specific that your app enables; help them get started right away by minimizing the steps that they need to take, especially when they’re first trying your app. If the first thing a user sees is a registration screen, many will bounce off (once you need the users to sign in, you can use OpenID and Google Accounts to simplify the process). By installing your app they’ve indicated something stronger than just clicking a link - they want to use your app to accomplish something specific. Keep the distractions to a minimum and keep your app focused on the job at hand and your users will be happier.

UI responsiveness in your app is also crucial. For example, let’s say you’ve built a photo stitching app that glues together photos into one seamless larger photo. This may require a lot of CPU horsepower or even that you do the heavy lifting on the server. Maybe the whole operation takes two minutes to complete. However, you can still keep your interactive performance high while the operation proceeds asynchronously. You could ship the CPU work off of the main user interface thread using an HTML5 Worker or you could offload it to a server with an XHR. That alone isn’t enough though. You need to give the user feedback while this is happening, ideally something cool and visual and not just a progress bar. Meanwhile, the user should be able to do other things. If that’s not possible, then cancelling needs to be easy and responsive. Interactive performance is usually something that needs to be designed into your app up front rather than added later as an afterthought, so plan ahead.

In short, you need to think both like app developer as well as a web developer. Putting a little extra thought into focus, performance, feedback and polish can make the difference between “meh” and “whee!”.

Today, we test five most popular web browsers to find out, who leads and who lags in the HTML5 Benchmark.

Browsers

Internet Explorer 8
Internet Explorer 9
Firefox 3.6
Firefox 4
Google Chrome 7
Google Chrome 8
Opera 11
Opera 10.6
Safari 5
WebKit

Results

Higher is better. Maximum score: 377 points.

Internet Explorer 8 – 32
Internet Explorer 9 Beta – 80
Firefox 3.6.10 – 145
Firefox 4 Beta 6 – 235
Google Chrome 7.0.517.41 – 248
Google Chrome 8.0.552.11 Beta – 262
Opera 11 Alpha – 223
Opera 10.63 – 203
Safari 5.0.2 – 178
WebKit r70433 – 196

Conclusion

As per our test, Google Chrome 8 takes the lead, followed by Google Chrome 7 and Firefox 4 Beta 6.

Unfortunately for Internet Explorer 9 and 8, they are in the bottom, followed by Firefox 3.6 and Safari 5.

Thanks to Nox for the tip.