RequestAnimationFrame not working when exiting fullscreen switching space on Safari

Question

Request animation frame stops working when exiting fullscreen by clicking on original space's safari window. Everything is fine if fullscreen mode is canceled with escape key or calling cancelFullScreen().

Steps to reproduce:

• open https://dl.dropboxusercontent.com/u/769042/prezi/safari-fullscreen.html
• click "draw with raf", a kittie appears
• click "fullscreen", you go fullscreen
• click "draw with raf", a kittie appears
• go back to the space where the original safari was, which is showing "click to exit fullscreen mode", click anywhere, you get out from fullscreen
• click "draw with raf", NOTHING HAPPENS

What it does is just handling the click calling:

window.requestAnimationFrame(draw);

which just draws something on a canvas context:

function draw() {
    ctx.drawImage(img, Math.random()*500|0, Math.random()*400|0, 100, 100);
}

I also checked the .hidden and .visibilityState, they get updated correctly.

Tested on osx 10.9.3, safari 7.0.4 (9537.76.4).

Has anyone any workaround/solution for this other than switching to the good old setTimeout?

Answer 1

This sounds like WebKit Bug 88940:

Using requestAnimationFrame and the fullscreen API on a DrawingArea-backed window would cause rAF to permanently suspend animations when fullscreened, because of the following:

1. JavaScript causes fullscreen transition to start.
2. Painting (and rAF) are suspended.
3. The page changes size. a. DrawingAreaProxyImpl::sizeDidChange() calls DrawingAreaImpl::updateBackingStoreState, which calls DrawingAreaImpl::resumePainting. b. DrawingAreaImpl::resumePainting resumes painting, but does not resume rAF, because windowIsVisible is (legitimately) false.
4. The view becomes visible, windowIsVisible is updated to true.
5. visibilityDidChange() calls resumePainting again, but this time it early exits because painting is not suspended.

Notice that because of the early exit in 4, rAF is never resumed.

Based on this description I suspect there is no effective workaround, since the drawing area gets into a state where calling resumePainting has no effect.

(Thanks to Jason Davies for finding this bug report.)