This fixes a cross-site-scripting vector where a javascript: URL could be loaded during the window.open (createNewPage) flow. When web content calls window.open, WebPageProxy::createNewPage asks the app’s UI client to create a new page; in a single-window app the client may respond by loading the requested URL into the existing view via WebPageProxy::loadRequest. A cross-origin subframe calling window.open(‘javascript:…’) could thereby get a javascript: URL loaded through this path and executed in the opener/host page’s context — a universal/cross-site scripting condition, because the javascript: URL runs with the wrong document’s origin rather than being blocked.

The fix adds an m_isCallingCreateNewPage flag: it is set true immediately before invoking the UI client’s createNewPage and cleared in the createNewPage completion handler, and WebPageProxy::loadRequest now returns nullptr (refusing the load) when m_isCallingCreateNewPage is true and request.url().protocolIsJavaScript().

The restored invariant is that javascript: URLs cannot be loaded through the createNewPage window. The regression test loads a javascript: URL via window.open from a cross-origin iframe and expects the loadRequest to be refused (NULL).

A cross-site scripting condition in the WebContent process reachable from a crafted iframe via window.open, letting attacker script run in another origin’s context — a serious same-origin-policy bypass. No memory corruption; the impact is universal XSS gated by the app’s window.open handling.