If frozen tab environment is detected, it is not displayed in the unsupported error on subsequent reloads.

[tejacques]

This can be resolved by combining the general detection check with the frozen tab environment check.

[KamalakannanPE]

Could you please put the code snippet to make this work ?

[tejacques]

Do you mean to have the error display, or to not have an error?

[KamalakannanPE]

I'm also getting the same frozenTabEnvironment error, so post the snippet to resolve the issue.

[tejacques]

The issue that was resolved here was properly reporting what the error was (i.e. Frozen Tab Environment detected). If you're seeing that in your error message then the error reporting is working correctly.

If you don't want this to happen, I need to know more about why it is happening. If you're on a mobile device, this will happen every time, which is currently by design. If you're on a desktop browser, you can try increasing the PING_TIMEOUT, or pulling the latest from master rather than NPM.

[gothy]

Hi

I'm getting crosstab not supported: frozen tab environment detected for IE11 in my custom setup(i'm using crosstab in the iframe on the page).
Not sure if I'm getting the whole case right, but IE is running in a kind of slow virtualbox environment and this PING_TIMEOUT thing might force FROZEN_TAB_ENVIRONMENT to be true.

I've tried to run the sample in this environment ( grunt + localhost:9000) and everything seems to be working as it should but closing the master tab in this test causes other tabs to update only after 5 seconds. crosstab.FROZEN_TAB_ENVIRONMENT in localStorage is false in the test environment.

Any ideas what can cause this kind of behaviour in my case?

Thanks

[tejacques]

Your intuition is most likely correct... the first thing I'd try is greatly increasing the timeout (maybe to like 10 seconds), and see what happens.

You should also clear all localStorage keys inbetween tests, as crosstab will try to use the stored value of whether or not it is supported.

If you find it's still reproducible, try to give me the steps to reproduce it on my end and I can take a look.

[gothy]

Digging into it revealed that localStorage in IE seems to be absolutely broken by design.
http://kntajus.blogspot.com/2014/08/local-storage-fundamentally-broken-in.html
https://connect.microsoft.com/IE/feedback/details/811546/ie11-localstorage-events-fire-twice-or-not-at-all-in-iframes
Even better!
https://connect.microsoft.com/IE/feedback/details/812563/ie-11-local-storage-synchronization-issues

Rising the PING_TIMEOUT or even all the timeouts didn't work.
So here's a starting point to see the problem:

• goto http://dev.modern.ie/tools/vms/#downloads and get a virtualbox image of IE11 on win8.1(IE10 is broken too, I guess)
• import to virtual box and launch
• put 10.0.2.2 host1 and 10.0.2.2 host2 to c:/window/system32/drivers/etc/hosts (for this launch Notepad as Admin)
• add host in ng-src of iframe in index.html
  ng-src="http://host1:9000/samples/index.html"
• open the IE, goto http://host1:9000
• open dev tools(F12), and set the document mode to Egde or IE10
• start adding tabs-iframes, see if everything is ok
• open another tab with http://host1:9000 and try to add more iframes
• open another tab with http://host2:9000 and try to add more iframes
• see how much I hate IE :)

[tejacques]

Aha, I'm aware of the first part of that bug, (see #11). Was never able to manifest the second part.

Could you open a new issue for this with the info you provided?

[tejacques]

Also, I can test this later tonight, but if you could check the behavior of the following, that would be really helpful:

• In what cases do Storage Events get sent, and in what cases do they not get sent?
  • Should test each case, so:
    • 1 -> 2
    • 1 -> 3
    • 2 -> 1
    • 2 -> 3
    • 3 -> 1
    • 3 -> 2
  • Cases are:

ID	Tab	Tab Host	Frame	Frame Host
1	1	host1	Window	host1
2	1	host1	iframe1	host1
3	2	host2	iframe2	host1

There are two pieces of info I'd like to know:

1. Does a storage event fire in each case when sent from each other case
2. Even if the event didn't fire, is the localStorage key readable / up to date in the other cases?

If the data is still readable and up to date, then there is a way to deal with this, similar to how I added Compatible Storage Events to IE8 in tejacques/IE8-EventListener, but it's sadly even uglier than that depending on what cases have successful communication. We can write a log of events to localStorage, and poll in the background on each tab looking through that queue. This does not miss any events, but it adds latency and overhead.

[gothy]

I've created a new issue.

This testing thing... I'm really exhausted now, after spending for all this crazy stuff more that a day, sorry.
I guess there's everything you need to know on IE issues in the links I've posted earlier.

My general interest is to get two tabs on unrelated domain to talk to each other over an iframe loaded from specific domain. It doesn't work for IE and that's what I know for sure, localStorage implementation for iframes is somehow completely isolated and the only solution people came up with is use the IndexedDB.
So I'm seriously thinking on dropping support for IE now. Time investments are starting to hurt :)

[tejacques]

That's fair -- thanks for making the issue and bringing this up. I'll try to look into a workable solution.

[gothy]

Hi there :)

I've made an experiment with IndexDB on Safari\IE11 and figured out that it's usage is restricted by security rules. So no common workarounds left to try that I'm aware of.
The only idea we've plans to try is very specific to our system, generally syncing tab state between tabs using custom UI-related events sent via a websocket.

Let me know if you'll come up with some kind of a good workaround for this stuff if you're still searching :)

[tejacques]

Hi @gothy. That's too bad about IndexedDB, thanks for letting me know. I still unfortunately haven't had time to devote to this yet, but I think that it can be resolved using a form of polling.

I will probably try to look into this over the weekend, but the main component of it is that I believe the view of localStorage updates even though a StorageEvent is not received, therefore in IE 10/11, a polling loop can be used to see if new events were written that weren't received. There would be a delay on these (perhaps configurable, but probably ~100-300 ms).

You also bring up a good point with regards to security rules -- Safari in Private Browsing mode will not allow use of localStorage. Some estimates put that usage in the 5-10% category (higher on certain types of websites).

[gothy]

I've tried polling in IE11, but it didn't work. In fact, behaviour was super weird.
Both tabs initially loaded with actually right values, but then writing to the storage in one tab's iframe and reading the value manually in context of another tab's iframe returned old(original value).
Only after browser restart I was actually able to read the latest stored value.

So it feels like these two storages were isolated one from another completely. Maybe I didn't get smth, but that's my experience is :(

[tejacques]

Ah that's interesting. The underlying model for localStorage on most (maybe all?) browsers is that each frame has it's own copy of localStorage, and changes propagate to other windows via the StorageEvents, so it would make some sense that localStorage is not updating because it isn't receiving the StorageEvent in the other windows/frames.

There are some other tricks which might work to force it to update/resync it's localStorage to the disk copy (restarting is one such thing which would do that). One example is writing to localStorage, another is opening an iframe.

I'll try to mess around with this soon. Worst case for IE10/11, it would need to either be the top level frame, or have access to window.top (so the top level would need to be on the same host). That's really unfortunate if it turns out to be the case.