Bug 110415 - Provide WKView SPI to defer telling the WebPageProxy and WebProcess about changes in the hosting window
Summary: Provide WKView SPI to defer telling the WebPageProxy and WebProcess about cha...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2013-02-20 17:30 PST by Tim Horton
Modified: 2013-02-20 19:53 PST (History)
3 users (show)

See Also:


Attachments
patch (4.60 KB, patch)
2013-02-20 17:35 PST, Tim Horton
simon.fraser: review-
Details | Formatted Diff | Diff
new names (4.73 KB, patch)
2013-02-20 18:56 PST, 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 2013-02-20 17:30:31 PST
Sometimes, we want to move a WKView around in the hierarchy.

Right now, if you remove a WKView and readd it elsewhere, you're likely to see a flash of white due to the asynchronous nature of the messages to the WebProcess (when a WebProcess is moved out-of-window, the TileCache unparents its tiles, among other things).

We should provide a way to say "hang on a second, I might re-add you to the same window in a bit".

I want to do this by simply providing a begin/end pair on WKView that - if you're inside a pair - we don't send WebPageProxy a viewStateDidChange with the ViewIsInWindow flag until you leave the last pair.

<rdar://problem/13095405>
Comment 1 Tim Horton 2013-02-20 17:35:53 PST
Created attachment 189425 [details]
patch
Comment 2 Simon Fraser (smfr) 2013-02-20 18:09:20 PST
Comment on attachment 189425 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=189425&action=review

Let's try some new names.

> Source/WebKit2/UIProcess/API/mac/WKView.mm:211
> +    unsigned _windowChangesDeferredCount;

viewInWindowDeferredCount?

> Source/WebKit2/UIProcess/API/mac/WKView.mm:1907
> +        if ([self windowChangesDeferred]) {
> +            _data->_page->viewStateDidChange(WebPageProxy::ViewIsVisible);
> +            _data->_windowChangeWasDeferred = YES;

The naming makes this confusing. It's easy to think that -windowChangesDeferred would return data->_windowChangeWasDeferred.

> Source/WebKit2/UIProcess/API/mac/WKViewPrivate.h:60
> +- (BOOL)windowChangesDeferred;

How about:

-beginDeferringViewInWindowChanges
-endDeferringViewInWindowChanges
-shouldDeferViewInWindowChanges
Comment 3 Tim Horton 2013-02-20 18:56:29 PST
Created attachment 189444 [details]
new names
Comment 4 Simon Fraser (smfr) 2013-02-20 19:49:29 PST
Comment on attachment 189444 [details]
new names

View in context: https://bugs.webkit.org/attachment.cgi?id=189444&action=review

> Source/WebKit2/UIProcess/API/mac/WKView.mm:213
> +    BOOL _windowChangeWasDeferred;

Want to rename this to 'viewInWindowChangeWasDeferred'?

> Source/WebKit2/UIProcess/API/mac/WKView.mm:3306
> +    if (!(--_data->_viewInWindowChangesDeferredCount) && _data->_windowChangeWasDeferred) {

Would be clearer to just hoist the --_data->_viewInWindowChangesDeferredCount outside the condition.
Comment 5 Tim Horton 2013-02-20 19:53:37 PST
http://trac.webkit.org/changeset/143558