In Chrome 46 on OSX sometimes frozen tab environment is detected

[tchakabam]

Is it possible that the detection sometimes has false positives for some reason, or that the timeout is simply too low? Maybe the detection mechanism is fuzzy or racing?

Could it be possible to make this automatic detection of "frozen tabs" optional?

It could be let to the application how to deal with the fact that a broadcast call might not reach all tabs eventually or with a substantial delay.

[tejacques]

The way this works is changing in v0.3.0. my best guess is that the ping was too low and the request timed out, causing it to record that the environment had frozen tabs. This won't be a show stopper on 0.3.0, it will gracefully fall back to not talking to other tabs, but still emitting events locally and acting as if it were the master tab.

[nibzo1]

I see this error occasionally, what exactly is the frozen tab environment? It prevents code I've implemented on top of crosstab functioning correctly.

When I do a count on the amount of tabs that are not the master tab it reports that there is 2 under the "frozen tab environment scenario" even though there is only one tab open

[tejacques]

A frozen tab environment is a browser environment, such as on a phone, where only a single tab/window is executing JavaScript at a time. In these situations, if a new tab believes another one is the master, and tries to communicate with it, it will never receive a response because the other tab is "frozen".

This is detected via a timeout, and when it is detected crosstab currently stops doing anything. In 0.3.0 this will change, and it will be treated as if the current tab is the only tab.

[nibzo1]

Thanks for the explanation and quick response.

Im using your excellent library to detect multiple tabs open on a web application and on detection forward the new tab to a static page (detailing that two tabs are open and they must continue with the original tab). The goal is to make the end user only use one tab, the master tab - or the first tab they opened.

All works well except the scenario described above, during the the frozen tab scenario the original tab doesn't know it is the master any more.

Ive tried to remove crosstab from the DOM clear localStorage and re-add cross tab again to try and reinitialise all.

[tejacques]

There's currently no great way to deal with false positive on frozen tab environment triggering. If you close all tabs, clear localStorage, and try again that will reset everything. If you discover it's giving you a frozen tab environment fairly frequently I'd like to know more about what your setup is. This happens if a second tab starting up does not receive a response from the master within the timeout.

[nibzo1]

I was able to reproduce this in a IE10 virtual machine. You explanation makes sense, I have upped the resources for the VM and the browser responds much quicker. I will assume I was hitting the timeout due to the speed the browser was preforming. It appears to function better now.

In reference to the 0.3.0 revision is this ready for use or is there still dev required.

[tejacques]

It's not production ready yet. This particular feature is mostly implemented but lacks a test suite. There are also several other features that are in development for 0.3.0.

I don't have a target release date as I only get to work on this project in my limited free time.

[nibzo1]

No problem, would you recommend Master for the momen?, I've cloned the current 0.3.0 branch which appears to work for me at present

[tejacques]

For now yes -- I'm working on fixing the outstanding bugs before continuing work on 0.3.0, but hopefully 0.3.0 will be released soon.

[nibzo1]

great thanks for the response

[nevcos]

Hi @tejacques,

I'm really concerned about this "frozen tab environment detected" error because sometimes it happens and there's no easy workaround for the user. And because crosstab is a really structural component on my app, the app itself becomes useless.

What's the most correct to programmatically deal with the problem? Can't you turn it optional as an fix for version 0.2.x?

[tejacques]

If it's critical for you to have something ASAP, I can pull in the timeout component of 0.3.0 to 0.2.x. What that will do is when a new tab is opened, it will ignore whether crosstab detected a frozen environment (or a good environment) if it happened more than 10 minutes ago, and try again fresh. This means that roughly each new "session" will go through the bootstrapping process of pinging the master.

This won't solve the problem that it can still detect a frozen tab environment, but it won't doom the application from working in the future if it happens. Does that work for you?

[nevcos]

Well, it's better indeed.

You don't like it to be an optional test? In my case the app will never be run on mobile. Or alternatively, can't the timeout be configurable? Or have optional retries? I know that timeouts are an enemy, but if the timeout time turns configurable, each application could adapt better to his context.

Thank you by the quick reply!

[tejacques]

It's not that I don't like those options -- those are both great ideas I would love to have, but it will require changing the API signature. I'm trying to adhere as closely as possible to semver with this project, so that would mean bumping the minor version. If you want something in 0.2.X it would have to be in this way or some other way that doesn't change the API.

I can also backport that much more easily since it already exists in the 0.3.0 branch.

I think most likely in 1.0.0 I will change it so that crosstab returns a function to create instances of cross-tab event emitters rather than being a singleton. That said I can probably add a configure function to 0.3.0 to take care of some of this.

[nevcos]

I love semver :+1:, and your idea on creating configurable instances of crosstab is very good.

I think that backporting it's a fair solution. Maybe it would not solve my problem, but then probably I would temporarily remove the frozen environment verification from the code (with a branch or a temporary copy on my project).

[taf2]

I found that the "frozen tab" e.g. no master issue here happens when you try to load a page with two iframe's. All tabs load in a frozen state and it seems to be be pretty reliable and happening in Chrome 47 as well as 46 now.

[tejacques]

Hi @taf2 can you supply the minimal steps to reproduce?