Bug 123557 - WebPageCreationParameters should be consistent in Window.open
Summary: WebPageCreationParameters should be consistent in Window.open
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2013-10-30 22:31 PDT by Gavin Barraclough
Modified: 2013-10-31 10:46 PDT (History)
0 users

See Also:

Fix (10.12 KB, patch)
2013-10-30 23:01 PDT, Gavin Barraclough
sam: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gavin Barraclough 2013-10-30 22:31:23 PDT
When Window.open in called in WebKit2 the WebProcess sends a synchronous request to open a page (WebPageProxy::createNewPage). The UIProcess creates a WebpageProxy, and responds with instructions to the WebProcess to create the WebPage. The initial creation state of the WebPage is communicated to the WebProcess via two routes (firstly an asynchronous WebProcess::CreateWebPage message, and secondly in the synchronous response from WebPageProxy::createNewPage). Unfortunately these responses are inconsistent with each other. The creationParameters() for the page are calculated twice, and since the WKView will be added to a window between the async message being sent and the synchronous reply being returned the visibility state of the page can change.

To fix the inconsistency we can set the creation parameters at the point that the WebPageProxy is instantiated. This will result in a functional change that is web visible, since the page will initially be opened in a hidden/blurred state, and may later become visible/focussed. This change is consistent with the direction we want to evolve in. Whilst we will still probably require a synchronous message from the WebProcess to the UIProcess on Window.open, we'll probably make this return much earlier – having just created the WebPageProxy, but avoiding blocking the WebProcess over the client delegate callback that opens the new window.

This fix results in a layout test result change, due to the change in behavior (page is created blurred, and becomes focussed, resulting in a focus event being fired – rather than the window opening directly into a focussed state). This is reported as a progression (test is broken in WebKit1, fixed in WebKit2 after this change). In reality the test is actually slightly broken in DRT/test-runner – the test runs differently than in browser, since there is is no visible main window. In-browser this patch results in no change in behavior on dom/Window/mozilla-focus-blur.html (the affected test).
Comment 1 Gavin Barraclough 2013-10-30 23:01:26 PDT
Created attachment 215619 [details]
Comment 2 Sam Weinig 2013-10-31 10:36:58 PDT
Comment on attachment 215619 [details]

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

> Source/WebKit2/UIProcess/WebPageProxy.cpp:3838
> +    WebPageCreationParameters& parameters = m_creationParameters;

You should not do this and instead just use m_creationParameters.
Comment 3 Gavin Barraclough 2013-10-31 10:46:58 PDT
Fixed in r158369