| Summary: | [wk2] Don't dispatch view state changes immediately | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Tim Horton <thorton> | ||||
| Component: | WebKit2 | Assignee: | Tim Horton <thorton> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | andersca, barraclough, mitz, simon.fraser | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
Created attachment 232843 [details]
patch
|
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).