2

I've the same problem depicted in iOS 5 pauses JavaScript when tab is not active thread.

My question is if I can be noticed when come back to the paused tab.

onfocus and onblur events don't work on to the to be paused tab.

The code:

<html xmlns="http://www.w3.org/1999/xhtml"> 
<head>
<script src="http://code.jquery.com/jquery-1.7.1.min.js" ></script>
<script type="text/javascript">
window.onblur = function () {
    console.log("blur");
    $("#whatevent").append("blur<br/>");
}
window.onfocus = function () {
    console.log("focus");
    $("#whatevent").append("focus<br/>");
 }
 window.onunload = function () {
       console.log("unload");
       $("#whatevent").append("unload<br/>");
 }
 window.onload = function () {
      console.log("load");
      $("#whatevent").append("load<br/>");
  }

</script>
</head>

<body>
    <div id="whatevent"></div>
</body>
</html>

none but onload (but only the first time I load the page) events works on iPad when I switch tab.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Luca Rasconi
  • 1,085
  • 11
  • 30

1 Answers1

2

Someone posed this very question over two years ago with this query. Unfortunately, it was met with only a couple of answers, one of which seems to be the only method to achieve this effect. Until Apple can implement the full Page Visibility API in mobile safari, I'm left with using this custom object I created that will use the API and fall back to a heart beat ticker if it's unavailable. However, as far as I can tell, there is no great way to check an imminent tab switch.

Here's a basic fiddle of the object demonstrating its only real method. It essentially just accepts a handler function for a focus event that gets fired whenever the browser returns the source tab. The fallback is hacky at best and will fire not just on a page re-entry but whenever scripting stops for longer than the timer threshold; which could be whenever the keyboard is visible, on scroll, or if a running script prevents the requestAnimationFrame from firing. Since scrolling is the most common behavior, I've added a handler that resets the last saved time so that the focus event refrains from firing.

This is the main portion of the script that includes the "hacky" method as described above:

    _that.onFocus = function(handler, params) {
        var hiddenProp = getHiddenProp();

        console.log("Hidden prop: " + hiddenProp);

        if (hiddenProp) {
            var evtName = hiddenProp.replace(/[H|h]idden/, "") + "visibilitychange";
            document.addEventListener(evtName, function(e) {
                if (isHidden()) {
                    handler(e, params);
                }
            }, false);
        }else {
            var handlerObj = {"handler": handler};
            if (params !== undefined) {handlerObj.params = params}
            _handlers.push(handlerObj);
            startLoop();
        }

    };

The rest may be read in the fiddle. In order to see the fallback you'll have to use a tablet (why else would you be needing this function without one?).

Note that the .onFocus method may accept an array of params for its second param that it will then pass to your event handler. This means that your event handler will always have an event object for it's first param (or null if the API is not supported) and your array of params as its second param.

Also not that this code has been tested for all of a couple hours so it may be prone to glitchiness. I would appreciate any constructive criticism to make it production worthy until Mobile Safari gets its butt in gear.

Community
  • 1
  • 1
MyNameIsKo
  • 2,171
  • 1
  • 15
  • 24