The Chromium Projects

Search this site

Except as otherwise noted, the content of this page is licensed under a Creative Commons Attribution 2.5 license, and examples are licensed under the BSD License.

Differences between Chrome and Chrome Frame

Contents

  1. 1 Introduction
  2. 2 HTML5
    1. 2.1 What works
    2. 2.2 What does not work
      1. 2.2.1 AppCache
      2. 2.2.2 Popup windows and window.opener
  3. 3 NETWORK STACK
    1. 3.1 Limitations
  4. 4 User Interface
    1. 4.1 Context Menu
      1. 4.1.1 Page Information
      2. 4.1.2 IE encoding menu option
      3. 4.1.3 This option which displays the list of encodings used by pages will not work for pages rendered in Chrome Frame.
      4. 4.1.4 IE color settings/fonts
  5. 5 MISCELLANEOUS DIFFERENCES
    1. 5.1 IE Extensions/Addons


Introduction

Chrome Frame brings Chrome’s goodness to older versions of Internet Explorer. In general almost all the features offered by Chrome’s rendering engine are readily available in Chrome Frame. So feature wise, Chrome Frame is very similar to Chrome and the differences are minor. They start to appear where the boundaries of Chrome and Internet Explorer meet. Those areas are popup windows, some user interface features and network stack. Lets look at some of those feature differences.

HTML5

What works

Chrome Frame supports HTML 5 features like canvas. WebM, <video>, <audio>, WebGL, CSS animations, WebSockets on the same lines as Chrome.

What does not work

AppCache

AppCache does not work as expected since it is supported by the Chrome network stack. Chrome Frame uses Internet Explorer’s network stack.

Popup windows and window.opener

Popup windows get complicated as either, or both of the main window and its popup can be rendered by Chrome Frame. We have two main cases:

  1. Both the main window and the popup window are rendered in Chrome Frame.

    Pages rendered in Chrome Frame via the window.open API can be scripted by the calling page only if the popup window URL is in the same origin as the calling page. This allows a web app to open popups and continue having a script connection. The script connection does not work for URLs from different origins

    window.opener relationships work in the same way, the popup can refer to window.opener only if it is in the same domain as the calling page.

    NOTE: If the main window and the popup are in different domains, the main page will not be able to script the popup page and window.opener will not work from the popup page.


  2. The main window is rendered in IE and the popup is rendered in Chrome Frame OR the main window is rendered in Chrome Frame and the popup is rendered in IE.

    In these two cases, window.opener in the popup page will not work. Neither will scripting the pop up page.

But.. this sucks, how do we communicate between windows on different domains? There are workarounds:

  1. Using the Chrome Frame ActiveX control as an intermediary for a host page rendered in IE to talk to a popup rendered in Chrome Frame.

    The Chrome Frame ActiveX control exposes a postMessage() method and callers can set an onmessage() handler. If a page on domain foo.com that does not enable CF wishes to communicate with a page on bar.com that does enable CF, the following approach can be used:
    The basic approach is as follows:

    1. The page on foo.com instantiates the CF ActiveX control and sets an onmessage handler.
    2. The ActiveX control is navigated to a helper page on bar.com that opens a popup window to another page on bar.com.
    3. The page hosted in the popup and the page hosted in the ActiveX control can communicate via postMessage().
    4. The page hosted in the ActiveX control can communicate with the page in the popup via postMessage() since they are on the same domain.
    5. With the page in the ActiveX control acting as a relay, this allows the host page on foo.com to communicate with any desired page on bar.com. 

    A demo of this approach with sample code and further explanation can be found here.


  2. Using an iframe as an intermediary for a host page rendered in Chrome Frame to talk to a popup rendered in Chrome Frame.

    Similar in approach as the above, in this case the Chrome Frame rendered host page uses an iframe instead of an embedded ActiveX control to enable working cross-domain messaging:

    The steps here are:

    1. The page on foo.com creates an iframe navigated to a relay page on bar.com. postMessage() will work between the iframe and its parent.
    2. The relay page on bar.com pops up a window navigated to another page on bar.com. These two pages can postMessage() back and forth since they are on the same domain. 
    3. The original hosting page on foo.com can now communicate with the popup page on bar.com using the bar.com page hosted in the iframe as a relay.

    A demo of this approach can be found here.

NETWORK STACK

Chrome Frame uses Internet Explorer’s network stack, i.e. HTTP/HTTPs requests issued by Chrome will be routed through Internet Explorer. This ensures that Chrome Frame shares the same session cookies, cache and honors Internet Explorer settings like proxy servers.

Chrome Frame routes HTTP/HTTPs requests to the host browser (IE) in the following cases:
  • Requests initiated when a page loads in Chrome Frame. Includes requests to download the HTML content of the page, resources on the pages, etc.
  • XHR, Websocket requests initiated by javascript code on the page.

Limitations

Requests initiated by the AppCache layer in the Chrome browser will go out through the Chrome network stack. This the reason why HTML5 AppCache does not work in Chrome Frame.

When HTTPs urls are loaded in Chrome Frame, certificate information is not passed to Chrome. This means that Chrome Frame will not be able to display information like certificate information, whether the connection is encrypted, etc for these pages. This is a User Interface issue only.

User Interface

Chrome Frame attempts to seamlessly integrate in Internet Explorer, i.e. pages loaded in Chrome Frame would provide a consistent user experience. Differences listed below:

Context Menu

Chrome Frame pages display Chrome’s context menu.

Page Information

The Page properties menu option in Internet Explorer will not display reliable page information for Chrome Frame pages.
Page information will not be available for HTTPs URL’s rendered in Chrome Frame. Please refer to the Network Stack section for reasoning behind this.

IE encoding menu option

This option which displays the list of encodings used by pages will not work for pages rendered in Chrome Frame.

IE color settings/fonts

Pages rendered in Chrome Frame will not honor Internet Explorer color settings and fonts. 

MISCELLANEOUS DIFFERENCES

IE Extensions/Addons

Internet Explorer extensions like Google Toolbar, Yahoo Companion, etc which expect to have access to the web page DOM to perform actions on the page will not work on Chrome Frame pages. Some other Internet Explorer extensions like Askbar, mgToolbarIE, SweetIM Toolbar, gbieh.dll, and G-Buster Browser Defense may crash when Chrome Frame pages are displayed.
Comments