Chrome 19 (just released to the stable channel) includes support for Web Intents, and the support is further improved in Chrome 20 (currently in the beta channel). One of the improvements is that downloaded RSS and Atom feeds will now dispatch a view intent. This is neat, getting things a bit closer to truly fixing one of the earliest Chrome bug reports. However, if you're occasionally engaged in some technology necrophilia, then you might prefer seeing the angle brackets instead of handing over the feed to another app.

To that end, I've made Feed Intent Viewer, a simple intent handler that shows the feed as pretty-printed XML. Once you install it, clicking on links such as this one will trigger the sheet shown on the right, and choosing the "Feed Intent Viewer" app will show you your beloved angle brackets.

It's implemented as a packaged app (source), so that all of the feed data is processed locally, instead of being sent to a server. Even better, the download system includes the downloaded data with the intent (as a Blob) so that it doesn't have to be re-fetched at all. When the intent is dispatched with just a URL, then the data is fetched via XMLHttpRequest (this explains why the app has the "your data on all websites" permission). The new-ish responseType property of XHR is used, so that it can also be read as a blob. The feed blob data is read via a FileReader into a string, so that some light pre-processing can happen (currently, just removal of stylesheets, allowing the raw XML can be displayed). Finally, the feed text is put back into a blob that's served with a text/xml MIME type. This makes WebKit's XML viewer kick in, saving me the trouble of actually having to pretty-print anything.

While writing this up, I got a sense of déjà vu, which turned out to be warranted: In 2007, I created a similar hack to get Firefox 2.0 to show pretty-printed XML for feeds, instead of something friendlier.

PicasaWeb albums have an option to download the entire album to Picasa, which comes in quite handy when you'd like to have a complete archive of the pictures taken at an event. However, PicasaWeb URLs now redirect to the view of the album in Google+, which doesn't expose the equivalent command. There is a workaround for this (append noredirect=1 to the PicasaWeb URL), but it's rather involved. As an easier alternative, here's a bookmarklet:

Download to Picasa

If you invoke it on a Google+ photo album page, it'll try to launch Picasa and download that album (unless the owner has disabled that option).

The pretty-printed version of the bookmarklet script is:

(function(){
  var ALBUM_URL_RE =
      new RegExp('https://plus\\.google\\.com/photos/(\\d+)/albums/(\\d+)[^?]*(\\?.+)?');
  var match = ALBUM_URL_RE.exec(location.href);
  if (match) {
    location.href = 'picasa://downloadfeed/?url=' +
        'https%3A%2F%2Fpicasaweb.google.com%2Fdata%2Ffeed%2Fback_compat%2Fuser%2F' + 
        match[1] + '%2Falbumid%2F' + match[2] + '%3F' +
        (match[3] ? encodeURIComponent(match[3].substring(1) + '&') : '') +
        'kind%3Dphoto%26alt%3Drss%26imgdl%3D1';
  } else {
    alert('Oops, not on a Google+ album page?');
  }
})();

The picasa://downloadfeed URL scheme was observed by looking at what happens when "Download to Picasa" is selected on a page through Chrome's DevTools' Network tab. The attempt at preserving query parameters is to that the authkey token and the like are passed on (unclear if it actually does anything though).