2

We have the following situation:

An Iframe is embedded and controlled by a page in one domain (A).

We do not have access to alter the code of domain A.

The content in the Iframe is delivered from another domain (B).

We are using sessionstorage to handle all session variables in the Iframe.

There is a Comet style push happening to deliver real-time updates to the Iframes and to make that work we need to be able to uniquely identify each Iframe.

For that purpose we store a unique ID in a sessionStorage variable and of course therein lies the problem.

All is fine until domain A opens a child window using "window.open" and we end up with the following scenario.

+----------+                +----------+
| A        |                | A        |
| +------+ |                | +------+ |
| | B (1)| | window.open -> | | B (2)| |
| +------+ |                | +------+ |
+----------+                +----------+

When B(2) is loaded the sessionstorage is handled as follows:

IE 8,9,10: sessionstorage[B1] is copied to sessionstorgage[B2]
Firefox:   sessionstorgage[B2] is uninitialized (this is OK)
Chrome:    sessionstorage[B1] is copied to sessionstorgage[B2]
Safari:    sessionstorage[B1] is copied to sessionstorgage[B2]
Opera:     sessionstorage[B1] is shared (ie the same) as sessionstorgage[B2]
           (a change in one will appear in the other - is this a bug?)

So ... the unique ID is cloned in most browsers (or shared in the case of Opera)

In Opera, because it appears to share the sessionstorage there will likely be no solution.

In Firefox we just act like a brand new window so there are no issues.

In Safari and Chrome we can do the following

if (window.opener)
{
    if (window.opener.frames.THE_IFRAME.sessionstorage.THE_UNIQUE_ID ==
        sessionstorage.THE_UNIQUE_ID)
    ... get a new unique ID ...
}

In IE we can't get access to the window.opener.frames.THE_IFRAME as it will not allow us to access anything at all in window.opener due to cross-domain restrictions.

Any suggestions of how to make this work in IE (We can live without Opera support), or for a better solution in general, would be greatly appreciated.

Stefan
  • 431
  • 4
  • 7
  • 2
    Opera's behaviour is the originally intended behaviour of the spec, but the gradual move to mutli-process browsers has basically killed it elsewhere. The behaviour is deliberately undefined. – gsnedders Jan 14 '13 at 21:01
  • `There is a Comet style push happening to deliver real-time updates to the Iframes and to make that work we need to be able to uniquely identify each Iframe.` Why not use WebSockets as transport layer ? 'coz its 2013 already, after all ;) For IE there are other ugly Comet techniques. See: http://stackoverflow.com/questions/2657450/how-does-gmail-do-comet-on-opera?lq=1 and http://ajaxpatterns.org/HTTP_Streaming – c69 Jan 15 '13 at 00:08
  • @c69 WebSockets would be nice as would HTML5 server-send. Unfortunately IE 8,9 support is required. Our HTTP streaming implementation works perfectly until we run into the problem of how to uniquely identify each Iframe instance. – Stefan Jan 15 '13 at 14:07

0 Answers0