If a WKWebView is removed from the view hierarchy and re-added in the same run-loop cycle, we shouldn't dispatch two "is-in-window" updates to the Web process. We should wait until just before CA is going to flush the (UI-process) layer tree, and dispatch them then (at that point, it's too late to re-add a view to the hierarchy for this run-loop cycle anyway). This avoids briefly suspending processes on iOS when moving views around in the hierarchy, and also performs a similar duty to WKView's non-sync variants of {begin, end}DeferringViewInWindowChanges, but without the app's manual intervention via SPI (and should ideally eventually allow us to get rid of that SPI on OS X as well).
Created attachment 232843 [details] patch
http://trac.webkit.org/changeset/169827