tejacques
commented
9 years ago Thanks for the continued thorough testing. The DOMContentLoaded approach can potentially add a significant latency, which I'd rather avoid if possible. This is especially apparent in requests that use tricks like flushing the head to load and execute scripts while generating the page.
This will require a lot of specific testing, but a dual strategy might work which looks like this:
script execution: start keepalive loop
beforeunload: stop keepalive loop, do cleanup, and add a listener on DOMContentLoaded that restarts the keepalive loop, and repeats any setup.
unload: stop keepalive loop / perform any necessary cleanup.
DOMContentLoaded: remove the beforeunload listener
This seems to work on IE11 in a simple test case:
<!doctype html>
<html>
<head>
<title>Testing</title>
<script>
window.addEventListener('DOMContentLoaded', function () {
console.log('DOMContentLoaded');
});
window.addEventListener('beforeunload', function () {
console.log('beforeunload - cancel refresh loop');
window.addEventListener('DOMContentLoaded', function () {
console.log('restart refresh loop');
});
return "Are you sure?";
});
window.addEventListener('unload', function () {
console.log('unload - cancel refresh loop');
});
</script>
</head>
<body>
<script src="//path/to/a/script/that/loads/really/slow.js"></script>
</body>
</html>Here's the chain I am seeing:
If the page is left before the DOM content is loaded, only the beforeunload event fires. If the page fully loads before it is left, beforeunload, and unload fire. If the page is left before the content is loaded, but is cancelled, the DOMContentLoaded event will fire once the page finishes loading.
I never saw a DOMContentLoaded fire after a page was attempted to be closed, and confirmed to close, so it would not re-start the keepalive loop unless it should.
I believe setting it up as described above should work, but requires more testing on various browsers.
alias-mac
@tejacques, sorry to bother you again, but we just found the most weird/bizarre issue in IE...
With a piece of code as simple as this, running in the body/head (not on document ready): http://jsfiddle.net/Ls3fbefj/1/
IE11 doesn't execute the unload function, only the
beforeunloadwhen refreshing while still loading (again hitting that sweet spot, since this doesn't happen all the time).See the highlighted part.
I'm not sure how this can be solved, since
beforeunloadis a cancelable event (like I explained in https://github.com/tejacques/crosstab/pull/31#issuecomment-113064771) we wouldn't be able to resume thekeepaliveLoop.Two things came to mind:
Solution 1:
The
crosstabbeforeunload function does what we are doing (canceling anysetTimeoutloop that might be executed at the end of the program stack) and at the bottom of the function we try to resume it in the nextTAB_TIMEOUTlike:I believe this solution will be problematic if the user takes
TAB_KEEPALIVEtime to sayyesornoin the confirmation box of the example I posted in https://github.com/tejacques/crosstab/pull/31#issuecomment-113064771 and I'm not sure here if the code will execute or not (at least consistently against all modern browsers).Solution 2:
We only start crosstab on document ready, wrapping the code near https://github.com/alias-mac/crosstab/blob/18ef65b8c471eb1bc5f634f73d700c3583f3af15/src/crosstab.js#L687:
We need to check if this would work normally on all browsers and if IE really executes the
unloadif the DOM is reported to be loaded (need to run some tests if you decide to go this way).Most the browsers also support this on document ready: http://caniuse.com/#search=DOMContentLoaded
There is still one problem with the frozen tabs even with any of the solutions posted above, when the browser crashes. If the browser crashes, the localStorage is maintained in it's last state (unless you have IE11 again and some weird settings - see http://stackoverflow.com/questions/24489542/localstorage-resets-in-ie11-after-closing-browser). In this event, how will we recover from frozen tab? Because we will try to ping the master tab that is gone (it was the window/tab that crashed).
Let me know which solution you think it is better or if we should drop frozen tab and find a different solution (like fallback to take over as the master tab and just resume everything - this will basically mean that if
crosstabisn't supported, it will assume it is master all the time and broadcast to itself, right?).