Google Chrome Frame — technical notes

Well, Google Chrome Frame has certainly taken the web dev world by storm. It’s almost as if people are fed up with Internet Explorer and welcome an alternative.

Many useful things have already been said about Frame. I’d like to add a few technical notes I haven’t yet encountered anywhere else.

Cache

When I was doing research I used one test page and constantly changed the <meta> tags in the <head>. The problem was that IE/Frame seemed to be caching not only the page, but also in which rendering engine it should be shown. Therefore a simple page refresh won’t help you here.

Fortunately Twitter user jdalton came up with a solution: simply append a pseudo-query such as ?123 to the page URL. That bypasses the cache and forces the browser to re-evaluate the <meta> tags.

Opting for Chrome Frame or IE8

The official way of enabling Chrome Frame for a web page is adding this meta tag to the <head>:

This is of course IE’s own syntax, and it seems to suggest Chrome Frame ties into the IE pre-parser, which is also responsible for detecting and executing the IE meta tags.

It turns out that only the first is executed. So the example above basically means “Please give me Chrome Frame, but if it’s not there I’ll settle for IE8.”

Now it reads: “Please give me IE8, but if it’s not there I’ll settle for Chrome Frame.”

This will doubtlessly be useful; it allows you to carefully distinguish between people who have Chrome Frame installed and those who don’t, and it also gives you the option to switch on Chrome Frame only for IE7 and lower.

Why stick with IE8?

If we suppose every single IE user installs Chrome Frame (a rather tall supposition), why would anyone want to stick with IE8?

First of all, there are a tiny number of CSS and JavaScript properties that are supported by IE8 but not (completely) by Chrome:

In all fairness, none of them are particularly important, although every once in a very great while these points could, in theory, be a reason to stick with IE8.

And of course the list with stuff that Chrome supports but IE8 doesn’t is much, much longer.

More serious is the fact that Chrome (Frame or not) does not support IE8 extras such as accelerators, web slices, and ARIA support.

I thoroughly like the Web Slices idea, although I’m lukewarm about accelerators. As to ARIA, that’s obviously very important, and the accessibility community doesn’t seem to be too taken with Frame.

So accessibility is actually an argument for sticking with IE8. Who’d have thought that only a few years ago?

Finally, Microsoft believes that Chrome Frame is less secure than IE, although Google claims the exact opposite. I have no opinion here — security is not my strong suit. Still, this question will likely be the most important one when it comes to actually installing Frame. Besides, I feel that Chrome Frame’s security should be compared not to IE8’s, but to IE6’s.

Will Frame be installed?

The big question of the moment is whether IE users, and then especially IE6 users, will install Chrome Frame to a meaningful degree.

As I said before, most IE6 users are trapped within that browser because the Intranet applications on their corporate network do not work in any other browser — not even IE7.

So in the end the decision lies with corporate sysadmins who either decide to update all browsers with Frame or not. On the positive side, Frame will not break any existing Intranet applications — if you leave out the <meta> tag IE6 will continue to act as IE6. So there’s no danger of Intranet apps not working.

On the other hand, corporate sysadmins are not the most progressive of people, and they will certainly want to test Chrome Frame before allowing it on their networks. It’s there that the security question will come into play, and that’s something I can’t say anything about because I just don’t know.

Comments

1 Posted by Andrea Giammarchi on 28 September 2009 | Permalink

Some other good point here. A note about the cache. You are testing! The scenario same page one click with and one click without meta is not a real case and, as we expect cache in both IE or Chrome, I expect same behavior with or without the meta. If the page wants Chrome, it won't change during navigation. If the page does not want cache, we all know how to force it via headers, rather than fake query strings. About IE apparently it's more about users habit, if they ignore the fact inside IE6 there is another browser, they feel better, so it seems to be a lie and legacy support just an excuse (too difficult to create a desktop icon wich points to that application via IE6, isn't it?) ... however, we should not forget that for some user Internet IS the blue E ... Finally, if the main goal is HTML5 support, Chrome Frame is not an option, but it's still a pre release, hopefully some gotcha will disappear with the stable one.

2 Posted by Tim Molendijk on 28 September 2009 | Permalink

I'm curious how in your experience the quality of the product is. Is it in a state in which it can be safely used by mainstream IE users? Will they be confronted with behavior that will confuse them? Is it stable? To summarize: how early-beta is it?

3 Posted by Vendetta on 28 September 2009 | Permalink

For the Cache Issues, Is Ctrl+F5 (Forced Reload) not working for refresh it?

4 Posted by Da Scritch on 28 September 2009 | Permalink

Security concerns could looks like Microsoft FUD, but, to have a good reflexion, what would happen if you have the Google plugin in IE8.

Now, what effectively happens when a malicious page is calling your e-bank page into the frame object and get credetials ?

I do repeat : this is a false security improving. It's a better option to let users intalling Google Chrome (or anything else) for internet surfing, and keeping MSIE6 for (stupid/badwritten/bigots/cheap) intranet applications. Even if it's not Wallon's cup of tea.

And it's a better economic and security option to trash all MSIE8- applications.

5 Posted by steve faulkner on 28 September 2009 | Permalink

"So accessibility is actually an argument for sticking with IE8."

No it's a reason for users of AT not to use chrome frame if they use IE, as it does not work for them, same as Google Chrome itself (http://www.paciellogroup.com/index.php?p=104). Its a reason to warn users that installing chrome frame will have bad effects on some pages and provide no positive effects if they use AT. It's a reason for users of AT to use Firefox if they can. It is also an argument for Google to get off their collective arses and use their substantial resources to make providing assistive technology support in Google Chrome a priority rather than a "nice to have" somewhere down the line...

6 Posted by Justin Ryan on 28 September 2009 | Permalink

Thank you for clarifying the effect of the meta tags. I had been following your tweets about using them, but didn't want to bypass IE8 entirely as it is actually pretty competent at rendering my pages the way I intended.

Your testing is well appreciated.

7 Posted by marcoos on 28 September 2009 | Permalink

You can also use semicolon-separates values in the meta tag, e.g. this meta tag:

also means: “Please give me Chrome Frame, but if it’s not there I’ll settle for IE8”.

8 Posted by Paul Irish on 28 September 2009 | Permalink

The other significant feature you lose in Chrome Frame is @font-face support.
I wrote it about it more here:
http://paulirish.com/2009/chrome-and-font-face-a-summary/

It appears as thought @font-face support is finally landing though, so we may see it soon in CF.

9 Posted by ryan.j on 2 October 2009 | Permalink

What i'm struggling with is who these users are: Users who are tech-savvy enough to realize IE is deficient, recognise chromeframe as a solution, find and install it, yet somehow cannot quite being themselves to use a different browser!

similarly, within a corporate environment it is entirely more likely they will require their apps to work with their current browser of choice, rather than rolling out a browser plugin company-wide.

chromeframe is an interesting idea, but as a concept i can't help but feel it's slightly flawed.

also phish-tacular, apparently.

10 Posted by tobyteel on 30 October 2009 | Permalink

As a web developer on a hefty web application, chrome frame is very interesting. We can boost javascript speed enormously for users with IE (7) using Chrome frame. Sure we still develop for IE 8 (and 7), but we recommend Chrome, Safari, or Firefox. Since we develop business applications, we may in the future recommend to (or force) companies stuck with an IE 6 intranet application to install Chrome frame to access our web applications. In this type of situation, CF could be very appealing: Corporate policies could still be maintained on IE, and a web proxy could strip meta and header tags to disable chrome frame for external pages, so IE 6 would still be used externally.

A note for Tim M: a lot of browser interaction doesn't work so well right now in Chrome Frame: File downloads and uploads, printing, and opening new windows all gave me trouble when I was testing it. We'll see where it goes.