Bug 133713 - [wk2] Don't dispatch view state changes immediately
Summary: [wk2] Don't dispatch view state changes immediately
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Tim Horton
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-10 19:15 PDT by Tim Horton
Modified: 2014-06-11 13:44 PDT (History)
4 users (show)

See Also:


Attachments
patch (7.35 KB, patch)
2014-06-10 19:20 PDT, Tim Horton
simon.fraser: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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]
patch
Comment 2 Tim Horton 2014-06-11 13:44:29 PDT
http://trac.webkit.org/changeset/169827