[Webkit-unassigned] [Bug 123557] New: WebPageCreationParameters should be consistent in Window.open

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=123557

           Summary: WebPageCreationParameters should be consistent in
                    Window.open
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit2
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: barraclough at apple.com


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).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.