Chromium Blog
News and developments from the open source browser project
Get your apps ready for the Chrome Web Store!
Thursday, August 19, 2010
Since our
announcement
of the Chrome Web Store at Google I/O, our team has been hard at work preparing for our launch later this year. Today we’re making the first step towards this milestone by making available a
developer preview of the Chrome Web Store
.
Developers can now start uploading apps and experiment with packaging them, installing them in Chrome (using the latest Chrome dev channel) and integrating our payments and user authentication infrastructure.
To get started, take a look at our recently updated documentation for
installable web apps
, which explains how to prepare and package your apps. You should also review some additional documentation we just released on the store’s
licensing
and
user authentication
features.
To upload your app, you’ll need to use the upload flow of the
Google Chrome Extensions Gallery
.
When the Chrome Web Store launches, it will replace the current gallery, featuring a completely new design for users to discover great apps, extensions and themes all in one place. Until then, only you can see the apps you upload - they will not be visible to other visitors of the gallery during this developer preview. In the meantime, you can continue to use the gallery for publishing Chrome extensions and making them available to Chrome users.
We look forward to sharing more news about the store and its features over the next weeks. Meanwhile, we encourage you to subscribe to our
developer discussion group
for apps and look for updates on the
Chromium blog
.
Posted by Michael Noth, Software Engineer
Security improvements and registration updates for the Google Chrome Extensions Gallery
Thursday, August 19, 2010
Since we introduced extensions in Google Chrome, we focused on making the platform more robust, by continuously exposing new APIs to developers. This has helped our
extensions gallery
blossom where more than 6,000 extensions are listed today and more than 10 million extensions are downloaded by Chrome users every month.
We designed security into the extensions system
from day 1
but we’re always looking for more ways to protect users. So, today, we are introducing two significant changes in the Google Chrome Extensions Gallery: a developer signup fee and a domain verification system.
The developer signup fee is a one-time payment of $5. It is intended to create better safeguards against fraudulent extensions in the gallery and limit the activity of malicious developer accounts. Starting today, this fee will be required to publish extensions, themes and soon apps in the gallery. We are waiving the fee for developers who already registered with the gallery (specifically before 11am PST today), so that they can continue to update their extensions and publish new items without paying the fee.
Domain verification is another addition that we believe will protect users and developers alike. Developers will be able to associate their extensions (and soon their apps) with domains they own or manage using
Google’s Webmaster Tools
. This way, they can clearly associate their extension with their brand and website, which in turn will help users identify “official” extensions in the gallery.
We believe that these are important improvements to the security of the gallery. We understand that changes like these can create a lot of questions, so please reach out to us on our
developer discussion group
for extensions.
Posted by Gregor Hochmuth, Product Manager
HTML5Rocks v2 - More Guides, New Studio
Friday, August 13, 2010
We think HTML5 will make your work more engaging and create a faster, more responsive experience for your users, so we're happy to add today a slew of new content to
html5rocks.com
.
If you want to not only get up to speed, but understand the browser differences and techniques for a robust implementation, please take a look through the new guides for implementing
HTML5 video
,
understanding "offline,"
auditing your webapp
with the Chrome developer tools, and using
web workers
and
@font-face
. You can now comment about your experiences with these features and stay up to date on new content via our new
RSS feed
.
We're also sharing the new
HTML5 Studio
, a collection of samples of these features in use, with code you can learn from and hack on.
If you'd like to contribute code, guides, or samples, please get in touch on the
bug tracker
or on
@ChromiumDev
. We'd love to incorporate your work.
Posted by Paul Irish, Google Chrome Developer Relations
Google Chrome in a Coal Mine
Monday, August 2, 2010
Since Google Chrome launched almost 2 years ago, the team has embraced the “launch early and often” strategy by releasing Dev channel builds almost weekly. But sometimes, such as when we’re in the process of moving a Dev channel release to the Beta channel, we’re unable to release a new Dev channel build, and other times, even a week is too long to wait to get feedback from the field on a change.
The team considered updating the Dev channel more frequently, but doing so would require us to forgo our manual testing pass on these builds. Even though the Dev channel is often rough around the edges, we realized that this lack of testing would result in a Dev channel that’s too unstable even for early adopters and developers. That’s why, a few days ago, we released a new experimental version of Google Chrome called Google Chrome Canary Build. We plan to update the Canary Build more frequently than the Dev channel, with riskier changes, and usually without a human being ever verifying that it works, so the Canary Build is only for users who want to help test Google Chrome and are comfortable using a highly unstable browser that will often break entirely. To enable you to continue using the same browser you love when the canary croaks, we’ve made it possible to install the Canary Build in addition to the Dev, Beta or Stable channel versions of Google Chrome.
The Canary Build is still brand new so it currently has a few limitations. Currently, it’s only available for Windows and cannot be set as your default browser. You can star the issues for
Mac
and
Linux
support, as well as the
issue
for default browser support to cast your vote and be notified of progress there.
If you like to live on the bleeding edge, give the
Google Chrome Canary Build
a shot and let us know what you think. The early feedback on crashes, performance regressions, broken features and other problems is incredibly valuable to us, so thanks!
Posted by Henry Bridge, Product Manager
Do You Know How Slow Your Web Page Is?
Wednesday, July 28, 2010
The
Web Timing
draft specification presents a standard set of metrics for measuring web page load time across browsers. We’re happy to announce that in
Chrome 6
, web developers can now access these new metrics under
window.webkitPerformance
.
Measuring web page load time is a notoriously tricky but
important
endeavor
. One of the most common challenges is simply getting a true start time. Historically, the earliest a web page could reliably begin measurement is when the browser begins to parse an HTML document (by marking a start time in a
<script>
block at the top of the document).
Unfortunately, that is too late to include a significant portion of the time web surfers spend waiting for the page: much of the time is spent fetching the page from the web server. To address this shortcoming, some clever web developers work around the problem by storing the navigation start time in a cookie during the previous page’s
onbeforeunload
handler. However, this doesn’t work for the critical first page load which likely has a cold cache.
Web Timing now gives developers the ability to measure the true page load time by including the time to request, generate, and receive the HTML document. The timeline below illustrates the metrics it provides. The vertical line labeled "Legacy navigation started" is the earliest time a web page can reliably measure without Web Timing. In this case, instead of a misleading 80ms load time, it is now possible to see that the user actually experienced a 274ms time. Including this missing phase will make your measurements appear to increase. It’s not because pages are getting slower – we’re just getting a better view on where the time is actually being spent.
Across other browsers: Web Timing metrics are under
window.msPerformance
in the
third platform preview
of Internet Explorer 9 and
work is underway
to add
window.mozPerformance
to Firefox. The specification is still being finalized, so expect slight changes before the browser prefixes are dropped. If you’re running a supported browser, please try the
Web Timing demonstration
and send us
feedback
.
Posted by Tony Gentilcore, Software Engineer
Release Early, Release Often
Thursday, July 22, 2010
Over the next few months, we are going to be rolling out a new release process to accelerate the pace at which Google Chrome stable releases become available. Running under ideal conditions, we will be looking to release a new stable version about once every six weeks, roughly twice as often as we do today.
So why the change? We have three fundamental goals in reducing the cycle time:
Shorten the release cycle and still get great features in front of users when they are ready
Make the schedule more predictable and easier to scope
Reduce the pressure on engineering to “make” a release
The first goal is fairly straightforward, given our pace of development. We have new features coming out all the time and do not want users to have to wait months before they can use them. While pace is important to us, we are all committed to maintaining high quality releases — if a feature is not ready, it will not ship in a stable release.
The second goal is about implementing good project management practice. Predictable fixed duration development periods allow us to determine how much work we can do in a fixed amount of time, and makes schedule communication simple. We basically wanted to operate more like trains leaving Grand Central Station (regularly scheduled and always on time), and less like taxis leaving the Bronx (ad hoc and unpredictable).
The third goal is about taking the pressure off software engineers to finish features in a single release cycle. Under the old model, when we faced a deadline with an incomplete feature, we had three options, all undesirable: (1) Engineers had to rush or work overtime to complete the feature by the deadline, (2) We delayed the release to complete that feature (which affected other un-related features), or (3) The feature was disabled and had to wait approximately 3 months for the next release. With the new schedule, if a given feature is not complete, it will simply ride on the the next release train when it’s ready. Since those trains come quickly and regularly (every six weeks), there is less stress.
So, get ready to see us pick up the pace and for new features to reach the stable channel more quickly. Since we are going to continue to increment our major versions with every new release (i.e. 6.0, 7.0, 8.0, 9.0) those numbers will start to move a little faster than before. Please don’t read too much into the pace of version number changes - they just mean we are moving through release cycles and we are geared up to get fresher releases into your hands!
Posted by Anthony Laforge, Program Manager
Celebrating Six Months of Chromium Security Rewards
Tuesday, July 20, 2010
It has been approximately six months since we launched the
Chromium Security Reward program
. Although still early days, the program has been a clear success. We have been notified of numerous bugs, and some of the participants have made it clear that it was the reward program that motivated them to get involved with Chromium security.
We maintain a list of issued rewards on the
Chromium security page
. As the list indicates, a range of researchers have sent us some great bugs and the rewards are flowing! This list should also help answer questions about which sort of bugs might qualify for rewards.
Today, we are modifying the program in two ways:
The maximum reward for a single bug has been increased to
$3,133.7
. We will most likely use this amout for
SecSeverity-Critical
bugs in Chromium. The increased reward reflects the fact that
the sandbox
makes it harder to find bugs of this severity.
Whilst the base reward for less serious bugs remains at $500, the panel will consider rewarding more for high-quality bug reports. Factors indicating a high-quality bug report might include a careful test case reduction, an accurate analysis of root cause, or productive discussion towards resolution.
Thanks to everyone who contributes to Chromium security, and here’s looking forward to our first elite entrant!
UPDATE
: We've had a few questions about whether we pay rewards in cases where the bug comes to us via a vulnerability broker. Bugs reported in this way are not likely to generate Chromium rewards. We encourage researchers to file bugs directly with us, as doing so helps us get started sooner on fixes and removes questions about who else may have access to the bug details. We'd also remind researchers that we don't necessarily require a working exploit in order to issue a reward. For example, evidence of memory corruption would typically be sufficient.
Posted by Chris Evans, Google Chrome Security
Making Chrome more accessible with extensions
Wednesday, June 30, 2010
Personalizing the web to match the needs and abilities of users is a big part of improving overall web accessibility. While we continue to
work hard
on making core Google Chrome more accessible, we're really excited about using browser extensions to improve the accessibility of the web for millions of users.
There are already
some extensions
among the more than 5,000 in the
gallery
that can benefit users with special needs. Some of these extensions use Chrome APIs and content scripts to alter the browser and manipulate the DOM of pages, offering users almost unlimited flexibility for viewing the web. Other extensions choose to implement altenative workflows, instead of adapting existing web page UIs, to give users faster access to content. These extensions benefit not just users of assistive technologies like screen readers but everyone who prefers access modes like keyboard shortcuts and captions.
If you are interested in making your extensions more accessible, we’ve created a new
Accessibility implementation guide
in the Chrome Extensions
Developer's Guide
that gives you an overview of accessibility best practices such as keyboard navigation, color contrast and text magnification. We’ve also
open sourced
the code behind
ChromeVis
, a new extension for users with low vision, so that you can use some of its code for manipulating text selection and magnification in your own extensions.
Already the NPR team has implemented some accessibility best practices in their
extension
. We hope to see more extensions adopting them. From our end, we're sponsoring a
Summer of Code project
to produce an extension that helps users produce custom style sheets and plan to create additional extensions that make navigating the web through Chrome easier.
We've also set up a
Google Moderator topic
where everyone can submit ideas for extensions that improve web accessibility. We hope these ideas will inspire extensions developers who are looking to create something useful for the community.
Stay tuned for future updates about Chrome Extensions and accessibility!
Posted by Rachel Shearer, Software Engineer
Enabling Adobe Flash Player support in Google Chrome’s stable channel
Wednesday, June 30, 2010
In March, we
announced
that we would be bringing improved support for Adobe Flash Player to Google Chrome. Along with driving the development of a
next generation browser plug-in API
, this integration will eliminate the need to install Flash Player separately and reduce the
security risk
of using outdated versions. In the near future, we will extend Chrome’s “
sandbox
” to web pages with Flash content to further protect users from malicious content.
We have been testing the integration in Google Chrome’s dev and beta channels over the last few months in order to ensure a quality experience for all our users. Over the last week, we have enabled the integration by default in the stable channel of Chrome.
Users who do not wish to use the built-in version of Flash Player in Chrome can disable the integration via the chrome://plugins manager. In this case, Chrome will fall back to the system-installed version of Flash Player, if it exists.
Posted by Jeff Chang, Product Manager
Improving plug-in security
Monday, June 28, 2010
Bad guys want to install persistent malware on your machine. Once they achieve this, they are free to do a variety of bad things such as steal your banking passwords, abuse your network connection, and rifle through your sensitive files.
Bad guys will install malware via the easiest path available. Traditionally, the easiest attack was to simply get a user to run an untrusted executable. Not all users fall for this. And modern operating systems and e-mail systems make this harder to do and restrict the permissions that the downloads run with -- making it less attractive. Next easiest is to exploit a disclosed vulnerability which is not yet patched by all users. The industry’s response to this is to autoupdate its users with security patches;
browsers including Firefox and Chrome
have demonstrated success at keeping the majority of their user bases current.
More advanced attacks involve finding undisclosed vulnerabilities in the browser. Despite being harder, there has been a lot of user damage due to exploitation of non-public bugs in browsers. Pleasingly, there’s a trend in modern browsers to integrate sandboxing. IE7 on Vista (and newer combinations) plus Google Chrome already have built-in sandboxes of varying strength. This makes many latent browser bugs incapable of persistently installing malware without a lot of additional effort to find a second bug to break out of the sandbox. Again, attackers favor the easiest attack so the increasing robustness of browsers is causing them to look elsewhere for ways to compromise user machines.
This brings us to the present time. We’re seeing a
remarkable swing
towards attacks that target pieces of browsing infrastructure
such as plug-ins
. This may be because browsers are taking the lead on auto-update and sandboxing. Since many plug-ins are ubiquitous, they pose the most significant risk to our user base. To better protect Google Chrome users from the threat of plug-in exploits, we have already announced a couple of initiatives:
More powerful plug-in controls
: Google Chrome now has the ability to disable individual plug-ins (about:plugins) or to operate in a “domain whitelist” mode whereby only trusted domains are permitted to load plug-ins (Options->Content Settings->Plug-ins).
Autoupdate for Adobe Flash Player
: By including Adobe Flash Player -- the most popular plug-in -- with Google Chrome, we can re-use Google Chrome’s powerful autoupdate strategy and minimize the window of risk for patched vulnerabilities.
There are more ways we are attacking the problem:
Integrated, sandboxed PDF viewing
: We have
announced
an integrated PDF viewer plug-in running inside Google Chrome’s sandbox. This will make it harder for PDF-based vulnerabilities to result in the persistent installation of malware.
Protection from out-of-date plug-ins
: Medium-term, Google Chrome will start refusing to run certain out-of-date plug-ins (and help the user update).
Warning before running infrequently used plug-ins
: Some plug-ins are widely installed but typically not required for today’s Internet experience. For most users, any attempt to instantiate such a plug-in is suspicious and Google Chrome will warn on this condition.
A next generation plug-in API
: “
Pepper
” makes it easier to sandbox plug-ins.
User safety is of paramount importance to us, including threats to our users caused by plug-ins outside of our direct control. We are working hard to improve the security of the entire browser ecosystem for Google Chrome users.
Posted by Chris Evans, Julien Tinnes, Michal Zalewski; Google Security Team
A fresh coat of chrome
Friday, June 25, 2010
As part of our continual work on Google Chrome’s user interface, we’ve been trying to streamline the toolbar, make the
Omnibox
more approachable, and communicate site security information more clearly. Users on our
dev channel
may have noticed some of these experiments already:
When you are typing into the Omnibox, an icon to the left will show how your input will be interpreted - such as a magnifying glass for search queries (
), and a globe for URLs (
). When you’re not typing, the same icon can be dragged to another document to copy the current page’s URL, or clicked to reveal information about the current site.
When on a secure (SSL) site, this icon changes to a lock (
) - previously we displayed the lock icon at the end of the Omnibox, but now it’s closer to the URL and in a more obvious place.
We’ve added a clearer presentation of Extended Validation (EV) certificate holder names (
), which, like the lock, are now at the beginning of the Omnibox.
We’ve changed the colors and icons used with secure sites to make mixed content more obvious, and avoid confusion about ambiguous colors.
In some situations, we’ve stopped displaying “http://” and/or a slash after the hostname. This makes the hostname more prominent and the URL more readable, and provides more visual distinction between regular and SSL websites (which keep their “https://” prefix). We’ve also done a lot of work to make sure that copying and pasting of these URLs continue to work as you would expect.
The bookmark star icon (
) has joined the other “page actions” at the right-hand side of the Omnibox.
Stop and Reload have been combined, and Go eliminated, to make things simpler and keep all the navigation-related toolbar buttons together.
Here’s a screenshot of the old interface in the stable channel (5.0), followed by the current interface on the dev channel (6.0):
More experiments are on the way to all platforms, like simplifying our menu structure, and further reducing visual noise in the toolbar:
In all these cases, we may tweak or even revert experiments before settling on a final solution. We’ve found that living with a new design is more informative than merely discussing it, so thanks to all our dev channel users for your patience and feedback as we test out these changes.
Posted by Nicholas Jitkoff, User Experience Designer
Extensions in Incognito
Thursday, June 24, 2010
When we first released extension support in Chromium, we left out all support for running extensions in incognito mode. This meant I had to live without handy extensions like
Mouse Stroke
and
PasswordMaker
(shameless plug) whenever I opened an incognito window, and that made me sad. When your muscle memory is trained to expect certain features, it's pretty jarring to find them missing. So in the latest stable version of Google Chrome, I added support for running extensions while in incognito.
One of the main reasons we delayed adding incognito support was that Chrome has no way to ensure that extensions obey the incognito rules: in short, that your browsing data is not saved after you close the incognito window. After much debate, we finally decided to let users decide which extensions they were comfortable using in incognito. You should only enable extensions that you trust and that don't save sensitive information. For example, an extension named Save All Your History would probably not be a good idea to run in incognito, since it would defeat the entire purpose of opening an incognito window. (This is not always the case: if the extension is written with incognito support in mind, it could avoid saving sensitive information, but it is up to the extension developer.)
To allow an extension to run while incognito, open the Extensions management page (accessible from the Tool menu -> Extensions). Each extension has an option to "Allow in incognito". Turning this on will let the extension display page and browser actions in incognito windows, and give them access to browser information originating from an incognito tab. It's just as easy to remove this access any time by following the same steps and unchecking the "Allow in incognito" option.
Note to extension developers:
Try to be a good citizen by only persisting browsing information collected from non-incognito windows. You can determine this by examining the
incognito
property on tab and window objects, or checking
chrome.extension.inIncognitoTab
from within a content script. For more information, see the extension documentation section on
Saving data and incognito mode
.
Posted by Matt Perry, Software Engineer
HTML5 Rocks!: A resource for open web developers
Tuesday, June 22, 2010
Because HTML5 and its related technologies cover so much ground, it can be a real challenge to get up to speed on them. That’s why today we're sharing
HTML5 Rocks
, a great new resource for developers and teams looking to put HTML5 to use today, including more information on specific features and when to use them in your apps.
We're launching the site with
nine tutorials
on specific HTML5 features. For example, you can learn how to successfully
take your application offline
,
access the user's location with Geolocation
, and even
read local files from within JavaScript
. In the site, we’ve also included a number of APIs that are defined outside the W3C HTML5 Spec, but kept them within this site as next-generation web applications span many specs. Watch the site as we’ll soon be adding more guides.
The
Interactive Presentation
, written in HTML5, demonstrates a number of features with examples you can toy with. You can use this presentation to learn more about HTML5, but also to conduct presentations with your team. Feel free to share it; all the content here is licensed
Creative Commons Attribution
.
The
code playground
lets you take working examples and edit them live, so you can get a feel for how the browser reacts to these APIs. And after you’ve hacked with, for example, the Notifications API, you can explore
handpicked resources
that include reference guides, development tools, and other community sites.
Send us a tweet at
@ChromiumDev
or post to the
Chromium HTML5 group
to let us know how we can improve the site for you. We look forward to seeing you experiment and build apps with these features!
Posted by Paul Irish, Google Chrome Developer Relations
Bringing improved PDF support to Google Chrome
Thursday, June 17, 2010
Millions of web users rely on PDF files every day to consume a wide variety of text and media content. To enable this, a number of plug-ins exist today which allow users to open PDF files inside their browsers.
As we’ve previously mentioned
, the traditional browser plug-in model, though powerful, presents challenges in compatibility, performance, and security. To overcome this, we’ve been working with the web community to help define a
next generation browser plug-in API
.
We have begun using this API to improve the experience of viewing and interacting with PDF files in Google Chrome. This mirrors
our efforts
to optimize the Adobe Flash Player experience in Chrome.
Today, we are
making available
an integrated PDF viewing experience in the Chrome developer channel for Windows and Mac, which can be enabled by visiting chrome://plugins. Linux support is on the way, and we will be enabling the integration by default in the developer channel in the coming weeks.
With this effort, we will accomplish the following:
PDF files will render as seamlessly as HTML web pages, and basic interactions will be no different than the same interactions with web pages (for example, zooming and searching will work as users expect). PDF rendering quality is still a work in progress, and we will improve it substantially before releasing it to the beta and stable channels.
To further protect users, PDF functionality will be contained within the security “
sandbox
” Chrome uses for web page rendering.
Users will automatically receive the latest version of Chrome’s PDF support; they won’t have to worry about manually updating any plug-ins or programs.
Currently, we do not support 100% of the advanced PDF features found in Adobe Reader, such as certain types of embedded media. However, for those users who rely on advanced features, we plan to give them the ability to launch Adobe Reader separately.
We would also like to work with the Adobe Reader team to bring the full PDF feature set to Chrome using the same
next generation browser plug-in API
.
We’re excited about the usability and security improvements this will bring to Chrome users, and we’ll continue to keep everyone updated on our efforts through this blog.
Posted by Marc Pawliger, Engineering Director
Google Chrome Frame - Now in Beta
Tuesday, June 8, 2010
Web developers have been itching to develop with HTML5 but have been held back by legacy browsers.
Google Chrome Frame
can help break this impasse by allowing applications to target HTML5 on versions of Internet Explorer. Today, we’re excited to announce that Google Chrome Frame has graduated from Developer Preview into Beta.
Since our
initial launch
, we've been listening to developers: Instead of adding new bells and whistles, we've fixed more than 200 bugs to make integration with Internet Explorer seamless while improving security, stability, and performance. For example, we’ve improved our handling of Internet Explorer’s InPrivate browsing, cache clearing, and cookie blocking. All of the enhancements and features of
Google Chrome 5.0
are available in Google Chrome Frame too, including HTML5 audio and video, canvas, geolocation, workers, and databases.
As we've worked on these improvements, we’ve been excited to see sites adopting Google Chrome Frame, including
Meebo
and all the blogs hosted by
WordPress
. In addition to our launch partner Google Wave, some other Google properties, including Orkut and YouTube are also relying on Google Chrome Frame to deliver HTML5 experiences to millions of users.
For those of you who want to develop HTML5 applications and deploy them broadly, we encourage you to
give Google Chrome Frame a try
. Existing users will be auto-updated to the beta, so if you downloaded Google Chrome Frame before, you’ll automatically get the new version. We’re also creating a new
dev channel
release, where you can try out the cutting-edge features we’re developing. For information on getting started with Google Chrome Frame, our project
documentation
is the place to start.
We’re always working hard to improve, so expect further enhancements and performance improvements in both the developer and beta versions in the coming weeks. You can help by giving us
feedback
and
filing bugs
, and we’ll have more to share in the days ahead.
Posted by Amit Joshi, Software Engineer, and Alex Russell, Software Engineer
Google Chrome Developer Update - Google I/O recap, new APIs
Monday, June 7, 2010
Google I/O recap
If you missed the
Day 1 keynote
this year, it was all about the open web. There were some amazing demos from Mugtug, TweetDeck, Adobe, and Sports Illustrated demonstrating the full potential of HTML5. There was a preview of
WebM/VP8
, a high-quality, open, and web-optimized video format. We saw the announcement of the
Chrome Web Store
, which later this year will provide a new and exciting channel for developers to distribute their web apps and reach new users. We also launched the
Google Font API
, which allows you to add high-quality web fonts to any web page. Lastly, there were all of the great
Chrome sessions
. Videos have been posted on the Google I/O website:
Developing with HTML5
Developing web apps for the Chrome Web Store
Beyond JavaScript: programming the web with native code
Chrome extensions - how-to
Google Chrome's Developer Tools
Using Google Chrome Frame
HTML5 status update
WebM Open Video Playback in HTML5
What's new for developers in Google Chrome?
The Google Chrome Dev channel is now up to
6.0.422.0
. It includes a bunch of new features to think about when developing your apps:
Desktop notifications
(new since our last developer update)
File API
and
FileReader API
: Drag and drop files from the desktop to the browser!
Native Client (NaCl) SDK
and
ports
: Run with
--enable-nacl
.
HTML5 sandbox attribute
Integrated Flash Player plugin: Run dev channel with
--enable-internal-flash
.
In addition to the above, there are new experimental extension APIs:
chrome.experimental.cookies
chrome.experimental.clipboard
chrome.experimental.omnibox
You can try out these features by launching a Dev-channel version of Google Chrome with the
--enable-experimental-extension-apis
flag and adding the ‘experimental’ permission in your
manifest.json
file. Please keep in mind that these features are still under development and are not 100% stable yet.
Upcoming developer events
For those of you based in New York, there’s an upcoming Chrome Extensions hackathon in our local office on June 10, 2010. We also have a five day DevFest starting June 28, 2010 in Sydney, Australia. Google Chrome will be featured on Wednesday, June 30. Stay tuned for more details!
For the latest news and upcoming developer events, subscribe to this blog and follow us on Twitter
@ChromiumDev
.
Posted by Eric Bidelman, Google Chrome Developer Relations
An update on Google Cloud Print
Monday, June 7, 2010
In April, we
announced
Google Cloud Print, a service that enables any app (web, mobile, desktop), on any device, OS, or browser, to print to any printer. Development is progressing quickly and we are now testing the service internally at Google. Those testing it are particularly excited about being able to print from their phones to any printer in the company. We hope to launch the service in the coming months.
Google Cloud Print will work with all printers, including those that are not themselves web-connected (we call these “legacy printers”). However, as we said in the April announcement, the best experience will be with a new generation of web-connected printers that are natively cloud aware. We are working with a number of printer manufacturers to bring cloud print capabilities to their printers. Today, HP
announced
a full suite of cloud-aware printers ranging from $99 consumer printers to business-oriented printers. This pioneering work is a big enabler for the cloud print vision and all these printers will work with Google Cloud Print out of the box.
Sundar Pichai, VP for Client Products at Google and I joined HP’s announcement today to demonstrate printing from Chrome OS and a mobile phone. We show that Google Cloud Print enables printing from any device, without drivers, and that the print job starts instantly. Check out the video below (I encourage you to watch the full video or if you want the Google segment it begins at 31:37).
Watch
live streaming video
from
hpkickoff
at livestream.com
If you are a developer interested in learning more about Google Cloud Print, first review our
documentation
then keep an eye on check-ins to the chromium.org project. Those who have been following know that we’ve already added preliminary printing support to Chromium OS via Google Cloud Print and our proxy (which enables legacy printers to work with the service) now runs on Windows, Mac, and Linux.
Posted by Mike Jazayeri, Group Product Manager
Google Chrome’s Developer Tools Improve Productivity
Friday, June 4, 2010
At Google I/O 2010 we
presented
on Google Chrome’s Developer Tools and enjoyed getting the in-person feedback from developers. We wanted to list some of the new and improved features we presented at I/O that set apart our tools in helping developers become more productive.
The Scripts panel now allows editing JavaScript without having to reload the page. Just double-click on the line in the function body while debugging and make your changes. We’ll patch the underlying optimized machine code at run-time and continue the execution. [
video
]
CPU profiler captures the state of your app at a rate of 1,000 samples per second without modifications to the running optimized machine code. The resulting tree view makes it easy to find out where to focus efforts on speeding up the web app. [
video
]
The new Timeline panel provides a simple view of the AJAX application execution. It records everything that happens in the browser from JavaScript execution to styles re-calculations and then visualizes it in a simple waterfall with timing information and traces to the source code. See the demo fragment at [
video
].
The improved Heap profiler can take snapshots of the JavaScript heap, visualize and compare them. This makes finding and fighting memory leaks a much easier task. See the demo fragment at [
video
].
We also
covered
a number of general Inspector improvements in the WebKit blog recently. Watch them live in the DevTools panel walk through from the I/O
video
.
We welcome feedback: to submit a bug or feature request please use the Chromium
issue tracker
and mention DevTools in the summary.
We hope you like the new improved Google Chrome Developer Tools. Note that some of the features above are only available on Google Chrome’s
Dev Channel
at this moment. For more info please check out the
DevTools
site.
Posted by Pavel Feldman, Software Engineer
WebSocket Protocol Updated
Wednesday, June 2, 2010
WebSocket is "TCP for the Web," a next-generation full-duplex communication technology for web applications being standardized as a part of
Web Applications 1.0
. The WebSocket protocol is more efficient than HTTP as used in Ajax, so it is more suitable for real time and dynamic web applications. WebSocket also provides a very simple API that can be used to communicate bidirectionally between the web browser and a server, so it makes it easy to develop such web apps.
We initially implemented WebSocket in WebKit, which has been available in WebKit nightly builds and in Google Chrome. The initial implementation was based on
draft-hixie-thewebsocketprotocol-75
. Early adopters were able to start developing web apps using WebSocket on real browsers, and provide feedback about the WebSocket specification.
Based on community feedback, the WebSocket specification has been updated to
draft-ietf-hybi-thewebsocketprotocol-00
(also known as draft-hixie-thewebsocketprotocol-76).
This version relaxes requirements on handshake messages to make it easier to implement with HTTP libraries, and introduces nonce-based challenge-response to protect from cross protocol attacks. These changes make it incompatible with draft-hixie-thewebsocketprotocol-75; a client implementation of -75 can’t talk with a server implementation of -76, and vice versa.
Developers should be aware that starting from WebKit nightly build r59903 and Chrome 6.0.414.0 (r47952), the client will talk to a server using -76 version of the protocol, so it will fail to open WebSocket connections with a WebSocket server based on draft-hixie-thewebsocketprotocol-75. Since -75 version of the protocol is obsoleted and no longer supported in future version of browsers, to support new clients you need to update the server implementation. (Note that Chrome 5 uses -75 version of protocol).
The WebSocket protocol is still actively being changed. Until there is more consensus, we will continue to update our implementation to follow the latest draft of specification, rather than worrying about breaking changes.
We’re more than happy to hear your feedback, and encourage you to file any bugs you find on our
issue tracker
.
Posted by Fumitoshi Ukai (鵜飼文敏), Software Engineer
In The Open, For RLZ
Wednesday, June 2, 2010
When we
released
a new stable version of Google Chrome last March, we tried to improve the transparency and
privacy
options of Google Chrome. One area where we’ve seen a lot of interest and questions is the
RLZ
library that is built into Google Chrome. RLZ gives us the ability to accurately measure the success of marketing promotions and distribution partnerships in order to meet our contractual and financial obligations. It assigns non-unique, non-personally identifiable promotion tracking labels to client products; these labels sometimes appear in Google search queries in Google Chrome.
Documenting Google Chrome’s use of promotional tags and tokens was a good start, but we wanted to take this transparency a step further. Our goal was to not only show you exactly how we were sending distribution information, but also what information was included and how it was generated.
Today, we’ve open-sourced the code that generates the RLZ parameter that sometimes appears in Google search queries. We’ve made the RLZ library its own
project
on the Google Code site, since this is the same library that is used in other Google products. This is analogous to how we opened
Omaha
, the Google Updater technology, as its own open-source project.
Chromium will also continue to exist as it always has, without any RLZ library included. And, you can still download a Google Chrome with no RLZ behavior at www.google.com/chrome. But now that RLZ is open, Google Chrome distributed through promotional means will include this open-source implementation of RLZ.
It is our hope that we are not only opening up a previously-closed part of Google Chrome and providing better transparency, but that we’re also offering up potentially useful code to others who may use it in their own projects.
We know this is just a small step, but we think that the RLZ project will provide better transparency and value to the community. We want to hear what you think, so please keep the feedback coming!
Posted by Roger Tawa, Software Engineer, and Glenn Wilson, Product Manager
Labels
$200K
1
10th birthday
4
abusive ads
1
abusive notifications
2
accessibility
3
ad blockers
1
ad blocking
2
advanced capabilities
1
android
2
anti abuse
1
anti-deception
1
background periodic sync
1
badging
1
benchmarks
1
beta
83
better ads standards
1
billing
1
birthday
4
blink
2
browser
2
browser interoperability
1
bundles
1
capabilities
6
capable web
1
cds
1
cds18
2
cds2018
1
chrome
35
chrome 81
1
chrome 83
2
chrome 84
2
chrome ads
1
chrome apps
5
Chrome dev
1
chrome dev summit
1
chrome dev summit 2018
1
chrome dev summit 2019
1
chrome developer
1
Chrome Developer Center
1
chrome developer summit
1
chrome devtools
1
Chrome extension
1
chrome extensions
3
Chrome Frame
1
Chrome lite
1
Chrome on Android
2
chrome on ios
1
Chrome on Mac
1
Chrome OS
1
chrome privacy
4
chrome releases
1
chrome security
10
chrome web store
32
chromedevtools
1
chromeframe
3
chromeos
4
chromeos.dev
1
chromium
9
cloud print
1
coalition
1
coalition for better ads
1
contact picker
1
content indexing
1
cookies
1
core web vitals
2
csrf
1
css
1
cumulative layout shift
1
custom tabs
1
dart
8
dashboard
1
Data Saver
3
Data saver desktop extension
1
day 2
1
deceptive installation
1
declarative net request api
1
design
2
developer dashboard
1
Developer Program Policy
2
developer website
1
devtools
13
digital event
1
discoverability
1
DNS-over-HTTPS
4
DoH
4
emoji
1
emscriptem
1
enterprise
1
extensions
27
Fast badging
1
faster web
1
features
1
feedback
2
field data
1
first input delay
1
Follow
1
fonts
1
form controls
1
frameworks
1
fugu
2
fund
1
funding
1
gdd
1
google earth
1
google event
1
google io 2019
1
google web developer
1
googlechrome
12
harmful ads
1
html5
11
HTTP/3
1
HTTPS
4
iframes
1
images
1
incognito
1
insecure forms
1
intent to explain
1
ios
1
ios Chrome
1
issue tracker
3
jank
1
javascript
5
lab data
1
labelling
1
largest contentful paint
1
launch
1
lazy-loading
1
lighthouse
2
linux
2
Lite Mode
2
Lite pages
1
loading interventions
1
loading optimizations
1
lock icon
1
long-tail
1
mac
1
manifest v3
2
metrics
2
microsoft edge
1
mixed forms
1
mobile
2
na
1
native client
8
native file system
1
New Features
5
notifications
1
octane
1
open web
4
origin trials
2
pagespeed insights
1
pagespeedinsights
1
passwords
1
payment handler
1
payment request
1
payments
2
performance
20
performance tools
1
permission UI
1
permissions
1
play store
1
portals
3
prefetching
1
privacy
2
privacy sandbox
4
private prefetch proxy
1
profile guided optimization
1
progressive web apps
2
Project Strobe
1
protection
1
pwa
1
QUIC
1
quieter permissions
1
releases
3
removals
1
rlz
1
root program
1
safe browsing
2
Secure DNS
2
security
36
site isolation
1
slow loading
1
sms receiver
1
spam policy
1
spdy
2
spectre
1
speed
4
ssl
2
store listing
1
strobe
2
subscription pages
1
suspicious site reporter extension
1
TCP
1
the fast and the curious
23
TLS
1
tools
1
tracing
1
transparency
1
trusted web activities
1
twa
2
user agent string
1
user data policy
1
v8
6
video
2
wasm
1
web
1
web apps
1
web assembly
2
web developers
1
web intents
1
web packaging
1
web payments
1
web platform
1
web request api
1
web vitals
1
web.dev
1
web.dev live
1
webapi
1
webassembly
1
webaudio
3
webgl
7
webkit
5
WebM
1
webmaster
1
webp
5
webrtc
6
websockets
5
webtiming
1
writable-files
1
yerba beuna center for the arts
1
Archive
2024
Jun
May
Apr
Mar
Feb
2023
Nov
Oct
Sep
Aug
Jun
May
Apr
Feb
2022
Dec
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2021
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2020
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2019
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2018
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2010
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2009
Dec
Nov
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2008
Dec
Nov
Oct
Sep
Feed
Follow @ChromiumDev
Give us feedback in our
Product Forums
.