Bug 133713

Summary: [wk2] Don't dispatch view state changes immediately
Product: WebKit Reporter: Tim Horton <thorton>
Component: WebKit2Assignee: Tim Horton <thorton>
Severity: Normal CC: andersca, barraclough, mitz, simon.fraser
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Description Flags
patch simon.fraser: review+

Description Tim Horton 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).
Comment 1 Tim Horton 2014-06-10 19:20:59 PDT
Created attachment 232843 [details]
Comment 2 Tim Horton 2014-06-11 13:44:29 PDT