RESOLVED FIXED 133713
[wk2] Don't dispatch view state changes immediately 
https://bugs.webkit.org/show_bug.cgi?id=133713
Summary [wk2] Don't dispatch view state changes immediately
Tim Horton
Reported 2014-06-10 19:15:08 PDT
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).
Attachments
patch (7.35 KB, patch)
2014-06-10 19:20 PDT, Tim Horton 		simon.fraser: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Tim Horton
Comment 1 2014-06-10 19:20:59 PDT
Created attachment 232843 [details] patch
Tim Horton
Comment 2 2014-06-11 13:44:29 PDT
http://trac.webkit.org/changeset/169827
Note You need to log in before you can comment on or make changes to this bug.