Thursday, December 10th, 2009

A busy Chrome week: Extensions, Web Sockets, and more

Category: Chrome, Google

<>p>It has been a busy work for Chrome, with some interesting features hitting the various “channels”.

Web Sockets

First up, we have Web Socket support being turned on by default on the developer channel. If you want to be a really cool JS h4x0r you should write a server app using node.js. If you want it to work on older browsers, try out the old favourite shim tale of use Flash to degrade, and Mozilla support should be coming soon and surely IE9 will support it too ;)

Now you can code like this:

javascript
< view plain text >
  1. if ("WebSocket" in window) {
  2.   var ws = new WebSocket("ws://example.com/service");
  3.   ws.onopen = function() {
  4.     // Web Socket is connected. You can send data by send() method.
  5.     ws.send("message to send"); ....
  6.   };
  7.   ws.onmessage = function (evt) { var received_msg = evt.data; ... };
  8.   ws.onclose = function() { // websocket is closed. };
  9. } else {
  10.   // the browser doesn't support WebSocket.
  11. }

Chrome Extensions Beta

Although I curse at the weak support on Chrome Mac (coming by end of week though!), other Chromers can use the new beta extension system pioneered by the awesome Aaron Boodman and team:

Today, we’re really happy to release a beta of extensions that begins to deliver on our initial vision. Extensions are as easy to create as webpages. Users can install and uninstall them quickly without restart, and extensions have a great polished look that fits in with Google Chrome’s minimalist aesthetic. When developers upload an extension it is available to users immediately, with limited restrictions and manual reviews only in a few situations.

On the technical side, we’ve been able to use Google Chrome’s multiprocess architecture to help keep extensions stable and safe. And Chromium’s extensive performance monitoring infrastructure has helped us ensure extensions affect Google Chrome’s speed as little as possible. You can learn more details about the internals of our system in the videos below.

I am excited about the new extension systems of Chrome and Jetpack, and wrote up thoughts on how we are jumping out of the page and into the runtime as Web developers.

rel=”noreferrer” and target=”_blank”

I missed the fact that in Chrome you can opt-in to a new process from a link. This is important as every tab is NOT necessarily in its own process. People assume that is the case (a one to one mapping) but it isn’t (and has interesting security implications):

In many cases, though, Google Chrome needs to keep pages from related tabs in the same process, since they may access each other’s contents using JavaScript code. For example, clicking links that open in a new window will generally cause the new and old pages to share a process.

In practice, web developers may find situations where they would like links to other pages to open in a separate process. As one example, links from messages in your webmail client would be nice to isolate from the webmail client itself. This is easy to achieve now, thanks to new support in WebKit for HTML5′s “noreferrer” link relation.

To cause a link to open in a separate process from your web page, just add rel=”noreferrer” and target=”_blank” as attributes to the tag, and then point it at a URL on a different domain name. For example:

Posted by Dion Almaer at 6:07 am
3 Comments

+++--
3.8 rating from 16 votes

3 Comments »

Comments feed TrackBack URI

I’ve been a Firefox fanboy for years, but Chrome is some nice software.

BTW guys you’ve got some weirdness going on in this post:

rel=”noreferrer” and target=”_blank”

is just below the YouTube video.

Comment by richtaur — December 12, 2009

great news!

Comment by alshur — December 15, 2009

great news fo us
thanks

Comment by Aphrodisiac — January 15, 2010

Leave a comment

You must be logged in to post a comment.