No, I don't want to right-click and reopen five tabs just to get back to the one Web page that I want reopened. I want choice! Give me a drop down menu that lets me choose from a selection of recently closed tabs -- like Opera does!
Fortunately, there's a new addition to the Google Chrome Extensions Gallery that bolts on this missing feature. Install Trash Can, and you'll get a handy icon in the browser actions area. As you close tabs in Google Chrome, they'll appear in Trash Can's menu; select only the tab you want, click it, and restore! That's much better.
As the developer states, it's pretty minimalistic right now. Future versions will add support for session saving, multiple Google Chrome windows, and the option to limit how many tabs you want remembered. While Incognito support is also mentioned, I found that Trash Can worked just fine in Chrome's private browsing mode.
ed note: The Recently Closed Tabs extension also offers this kind of functionality (with a few additions like favicons and tumbnails), but it uses about 5x as much memory as Trash Can.
Many Chrome extensions use browser actions as a notification area. Notifications can be very valuable to users, but there’s only so much a developer can do with an icon’s worth of pixels.
As it turns out, web sites have a great way to deliver non-modal message like these with the notifications API, which was first introduced in Chrome 4 for Windows.
As of Chrome 5, we’re happy to announce that notifications are also available to extension developers.
When notifications are used from an extension, there are no permission prompts or infobar warnings. The experience is seamless - it just works.
To learn how to use the notifications API in your extension, review our documentation. We’ll be on the lookout for some great examples of desktop notifications to feature on the Chrome Extensions Gallery, so get cracking!
As part of the Developer Relations team at Google, we get the chance to run lots of different types of events. Some of the most rewarding are hackathons that involve writing Google Chrome Extensions. We always love watching developers create useful features for Google Chrome in just a few hours.
Recently, our friends at Twilio ran their own online Chrome Extensions hackathon. The winners, Brad Berkin and Timothee Boucher, used the Twilio API to integrate the Twilio and Chrome Extensions platforms, adding cool new functionality to Google Chrome.
Brad’s Chro-wilio extension tells you how many notifications, calls, and messages you’ve received in your Twilio account in the last day, week, or month. Timothee’s Notwilfications extension lets you know when a call is routed to your account. You can check who’s calling and either ignore the call or send it to voicemail without ever having to pick up your phone. When voicemail messages are recorded, a toolbar badge will show you the number of messages you have and let you play them right in the browser.
We’d like to thank all the developers who participated in this contest, as well as the Twilio team for organizing it. You can find more info about the contest on Twilio’s blog.
For those of you who missed this opportunity and are based in New York, we’re planning a Chrome Extensions hackathon in our local office on June 10th. If you’re interested in attending, all you need to do is fill out this form before June 6th. Space is limited, but we’ll try to accommodate everyone who signs up. We hope to see you there!
My Google Reader was a-buzzin' this morning with talk about ChromeDeck, a utility designed to create and manage multiple Google Chrome profiles. Truth is, it's pretty easy to do this without using a 3rd-party program.
The first step is to add a command line switch to your Google Chrome (or Chromium) shortcut: --enable-udd-profiles. If you need help figuring out how to add a switch, check our tutorial post -- Windows and Linux users follow pretty much the same steps, while Mac users may just want to launch the command from a terminal session.
Once you've added the switch, double-click your shortcut to launch Chrome. Once it's loaded, press control + M to invoke the profile selection menu. You'll have two options initially: default (what you're using right now) and new profile.
Create a new profile, and Chrome will automatically launch a new window with it enabled. You can even run the windows side-by-side, which can be handy for testing web projects, that new extension you're coding, or even just keeping tabs on multiple webmail accounts.
You'll also have the option of creating a desktop shortcut to open Chrome with your new profile. You may notice a little weirdness on your taskbar if you're using Windows 7 and running multiple windows with different profiles simultaneously. One of my icons showed a jumplist, the other did not -- but it did show per-tab thumbnail previews (and the original did not).
While creating new profiles and switching between them isn't that hard using Chrome itself, managing them isn't so easy. For that task, ChromeDeck is actually quite handy -- just make sure you've got .Net 4.0 installed.
With the latest release of Google Chrome, Chrome is the first browser to include support for a new HTML5 feature that lets web developers reduce the privileges of parts of their web pages by including a “sandbox” attribute in iframes:
You can give untrusted.html some of its privileges back by whitelisting the privileges in the value of the sandbox attribute. For example, if you wanted untrusted.html to be able to run scripts and contain forms, you could use the following markup:
Because @sandbox is a white list, the browser still imposes the remainder of the sandbox restrictions on untrusted.html. For example, untrusted.html does not have the privilege to create popup windows or instantiate plug-ins. The full list of supported directives is listed in the HTML5 specification.
When using the sandbox attribute, you need to think carefully about how legacy browsers (which do not support @sandbox) will interpret your HTML. The easiest way to use @sandbox is for “defense-in-depth.” Instead of relying upon @sandbox as your only line of defense, you can use it as an additional security mitigation in case your first line of defense (such as output encoding) fails. Because legacy browsers ignore attributes they do not understand, you can add @sandbox to existing iframes and improve security for users of newer browsers.
With continued improvements in plugin support, extensions functionality, and desktop integration, as well as new features such as desktop notifications and bookmark sync, we believe this release of Google Chrome for Linux to be a solid, high-performance, fully-featured, all-purpose browser. From the early porting days of layout test fixing, deep and hairy posix and raw X11 code, to designing a truly native UI and building a host of new and polished features, we’re thrilled to work with the larger community to deliver a fast, stable, secure, and sophisticated browser.
Going forward, we are committed to continuing to deliver all the security, performance, and features (old and new) of Google Chrome for Windows, while integrating as seamlessly as possible with the Linux desktop ecosystem on a variety of popular Linux distributions.
This is something I always asked myself. How is Google Chrome different from Chromium. Apart from the logo, there is hardly any difference visually between the two. So I decided to dig further. Here are some of the interesting facts you should know.
A developer preview of WebM, a high-quality, open, freely implementable, and web-optimized video format was announced today. Initial support for WebM, including its video codec VP8 will be checked into Chromium later tonight. You can try it by building Chromium yourself or watch for it in the dev channel build in the coming weeks.
We believe it should be easier for users to discover web apps and for developers to reach a large audience. That’s why today at Google I/O, we announced the Chrome Web Store, an open marketplace for web apps.
Google Chrome users who find web apps in the store will be able to create convenient shortcuts in Chrome for easy access. Also, developers will have the option to easily sell their apps through the store using a convenient and secure payment system.
To give you a preview of what it means to prepare a web app for the store, we've published some preliminary documentation. We look forward to your feedback and sharing our progress with you openly as many of the technical details will likely change before we launch. To stay up-to-date, subscribe to our developer group and look for news on the Chromium blog.
The Chrome Web Store will be available to users later this year. We plan to share more technical details soon. In the meantime, visit chrome.google.com/webstore for more information.
Today, we’re happy to make available a developer preview of the Native Client SDK – an important first step in making Native Client more accessible as a tool for developing real web applications.
When we released the research version of Native Client a year ago, we offered a snapshot of our source tree that developers could download and tinker with, but the download was big and cumbersome to use. The Native Client SDK preview, in contrast, includes just the basics you need to get started writing an app in minutes: a GCC-based compiler for creating x86-32 or x86-64 binaries from C or C++ source code, ports of popular open source projects like zlib, Lua, and libjpeg, and a few samples that will help you get you started developing with the NPAPI Pepper Extensions. Taken together, the SDK lets you write C/C++ code that works seamlessly in Chromium and gives you access to powerful APIs to build your web app.
To get started with the SDK preview, grab a copy of the download at code.google.com/p/nativeclient-sdk. You’ll also need a recent build of Chromium started with the --enable-nacl command-line flag to test the samples and your apps. Because the SDK relies on NPAPI Pepper extensions that are currently only available in Chromium, the SDK won’t work with the Native Client browser plug-ins.
We launched the O3D API about a year ago to start a discussion within the web community about establishing a new standard for 3D graphics on the web. Since then, we’ve also helped develop WebGL, a 3D graphics API based on OpenGL ES 2.0 that has gradually emerged as a standard, and is supported by other browser and hardware vendors like Mozilla, Apple and Opera.
The Google Chrome Developer Relations team has been working hard to spread the word about Google Chrome’s extensions platform and support for HTML5. Besides speaking at developer events around Silicon Valley, we’ve made it a priority to connect with developers in other locations in and out of the United States.
Following our trips last year to the Czech Republic, Russia, and Argentina, we spent a good chunk of the past few months on the road meeting with hundreds of developers and Google Technology User Groups.
For starters, Brian Kennish spoke about advanced extensions at Google DevFest in Tokyo, Japan and Google’s South by Southwest Interactive booth in Austin, Texas. You can check out a video of Brian’s DevFest session.
Next, Ernest Delgado, Jeremy Orlow, and Arne Roomann-Kurrik presented extensions and HTML5 to developers in London, England. Both presentations were actually implemented using HTML5 — the extensions deck as an extension and the HTML5 deck as a webpage.
Since our launch last December, all of us on the Google Chrome Extensions team have been excited to see a steady stream of new developers trying out our platform. Besides reading our documentation, Twitter account and our blog posts, a great way for an interested developer to get up to speed has been to participate in the extensions community. For example, in our discussion group, experienced developers often provide advice and answer questions for those working on their first extensions.
We wanted to take this community knowledge sharing process a step further. We reached out to our friends at Aviary, Zemanta, Web of Trust and Glue and had them discuss their experiences with Chrome extensions on camera. In the videos below, you’ll learn some of the innovative approaches developers from these companies used to create their extensions. You’ll also hear about the technical challenges they faced, the techniques they used to make their extensions more popular, and some of their upcoming plans:
We’re sure that these short videos did not answer all the questions you have, so if you’re attending the Google I/O conference on May 19th, make sure to stop by the sandbox area and meet the Zemanta, Aviary, Web of Trust and Glue teams in person. They’ll be happy to share the benefit of their experiences with anyone looking to write a Google Chrome extension. If you can’t attend, make sure to get involved with the community and we’ll get you on your way to making an excellent Google Chrome extension.
One of the most recent builds of the Chromium web browser is drawing some criticism. As you may know, Chromium is the open source browser project that Google’s Chrome web browser is based on. In the Chromium version 5.0.375.3, something new showed up. The address bar was not displaying the normal “http://” in front of addresses. It was reported in the issues at Chromium’s code site as a possible bug.
However, it turns out that this is an intentional move, and it’s started a fairly heated debate there. Some of the people posting there do not want to have the http prefix removed. Some people argue that it’s a feature that everyone will eventually want.
Apparently, if you need to copy and paste the address from the Chromium address bar, it will automatically add the “http” prefix, even though you don’t see it. This will need to happen in order to use copied URLs in other applications.
In my opinion, I don’t think it’s going to be a problem as long as the feature works as they say it will. I sometimes wonder why we even need to type the “www” in the address. It’s a waste of time and I’ll be happy if it goes away for good.
Vimium is an incredible Chrome add-on for keyboard-only Web navigation. Its basic shortcuts are modeled after those used in the ubergeek-oriented Vim text editor. The idea behind Vimium is that all of the most common actions (scrolling up and down, switching tabs, zooming) can be done using keys that are either on the home row of the keyboard, or otherwise very easy to reach (such as "zi" for Zoom In). Fortunately, they can be customized. That's one of the main things I like about it, since I use an alternative keyboard layout (Colemak). Once you get used to the shortcuts, you can do just about anything (navigate to links, find text, switch tabs, zoom in and out) without moving your fingers, much less reaching for the mouse.
When we demonstrated Google Chrome OS last Fall, a few folks asked us how it would handle printing. Today we wanted to give developers a little more insight into our approach for printing from Chrome OS and other web-connected platforms.
While the emergence of cloud and mobile computing has provided users with access to information and personal documents from virtually any device, today’s printers still require installing drivers which makes printing impossible from most of these new devices. Developing and maintaining print subsystems for every combination of hardware and operating system-- from desktops to netbooks to mobile devices -- simply isn't feasible.
Since in Google Chrome OS all applications are web apps, we wanted to design a printing experience that would enable web apps to give users the full printing capabilities that native apps have today. Using the one component all major devices and operating systems have in common-- access to the cloud-- today we're introducing some preliminary designs for a project called Google Cloud Print, a service that enables any application (web, desktop, or mobile) on any device to print to any printer.
Rather than rely on the local operating system (or drivers) to print, apps can use Google Cloud Print to submit and manage print jobs. Google Cloud Print will then be responsible for sending the print job to the appropriate printer with the particular options the user selected, and returning the job status to the app.
Google Cloud Print is still under development, but today we are making code and documentation public as part of the open-source Chromium and Chromium OS projects. While we are still in the early days of this project, we want to be as transparent as possible about all aspects of our design and engage the community in identifying the right set of open standards to make cloud-based printing ubiquitous. You can view our design docs and outlines here and we hope you stay tuned for updates in the coming months.