Bug 131434 - [WK2] When running in multi-process mode, opening link in new window from context menu creates blank window
Summary: [WK2] When running in multi-process mode, opening link in new window from con...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-09 06:07 PDT by Maciej Florek
Modified: 2014-04-11 10:25 PDT (History)
2 users (show)

See Also:

Attachments
Patch proposal to discuss (1.92 KB, patch)
2014-04-09 07:16 PDT, Maciej Florek 		no flags Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Florek 2014-04-09 06:07:33 PDT 
When running WK2 in multi-process mode (ie Minibrowser with -S switch on EFL port), opening link in new window ("Open link in new window" option in context menu), the newly created window is blank.
Comment 1 Maciej Florek 2014-04-09 07:16:42 PDT 
Created attachment 228960 [details]
Patch proposal to discuss
Comment 2 Maciej Florek 2014-04-09 07:17:13 PDT 
The problem is in WebChromeClient::createWindow() function. It creates ( by means of WebProcess::shared().createWebPage() ) a new web page in its own WebProcess, which is associated to the current web page (on which the context menu was invoked). So now there are two WebPages in one Webprocess. 

But few lines before, the message was sent to the WebPageProxy, to create new page. And in UI process a new WebProcessProxy with new WebPageProxy is created, and finally the new WebProcess is launched. Newly created blank window is associated to newly created WebProcess. 

The first web process tries to pass url to newly created web page, but it sends it to the page in its own process.

I have attached a draft of the patch to discuss. Url loading was moved to UI process, and the creation of new page in WebProcess was removed.

The problem is, that on "WebChromeClient::createWindow()" function result (which now is null) depends many other functions...
Comment 3 Alexey Proskuryakov 2014-04-11 10:24:07 PDT 
New windows opened with window.open need to be in the same WebProcess, because they are accessible via JavaScript.

So, this is an issue in Efl on UI side, it should know to create a new WebPageProxy in the same process.
Comment 4 Alexey Proskuryakov 2014-04-11 10:25:12 PDT 
Could also be an issue in MiniBrowser - I know that Safari implements opening in the same process when necessary, but don't know about MiniBrowser.