haikuwebkit/Source/WebCore/page/RemoteFrame.h

73 lines
2.6 KiB
C
Raw Permalink Normal View History

Introduce remote variants of Frame / DOMWindow classes https://bugs.webkit.org/show_bug.cgi?id=184467 <rdar://problem/39011267> Reviewed by Ryosuke Niwa. Introduce remote variants of Frame / DOMWindow classes, for when these frames / windows are hosted on another WebProcess. Those will be used in a follow-up patch. The hierarchy is as follows (class naming will be improved in a follow-up patch to minimise patch size): - AbstractFrame: A frame that can be either local or remote (hosted on another WebProcess) - Frame: A local frame - RemoteFrame: A frame hosted on another WebProcess. A RemoteFrame's window is also remote. - AbstractDOMWindow: A window that be either local or remote (hosted on another WebProcess) - DOMWindow: A local DOMWindow - RemoteDOMWindow: A window hosted on another WebProcess. A RemoteDOMWindow's frame is also remote. A RemoteDOMWindow is always cross-origin. This patch introduces global identifiers (unique across all WebProcesses) for both Frames and Windows. This is useful as we need to know which Frame / DOMWindow a particular RemoteFrame / RemoteDOMWindow is pointing to. Follow-up patch will add support for converting a local DOMWindow / Frame into a remote ones, when a newly opened window (via window.open) is navigated cross-origin (Bug 184515). Other things we'll need to implement in follow-ups: - RemoteDOMWindow will need to know about its opener in order to support the window.opener API. Internally, the opener will be stored as a RemoteFrame so that window.opener always returns the current window in the opener frame (which changes upon navigation). - Nullify a RemoteDOMWindow's frame whenever the window it is pointing to becomes frameless. A frameless window behaves very differently (e.g. very little API is exposed to the Web). This happens when either the newly opened window is either closed or navigated. * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * loader/ContentFilter.cpp: (WebCore::ContentFilter::didDecide): * page/AbstractDOMWindow.cpp: Added. (WebCore::AbstractDOMWindow::AbstractDOMWindow): (WebCore::AbstractDOMWindow::~AbstractDOMWindow): * page/AbstractDOMWindow.h: Added. (WebCore::AbstractDOMWindow::identifier const): * page/AbstractFrame.cpp: Added. (WebCore::AbstractFrame::AbstractFrame): (WebCore::AbstractFrame::~AbstractFrame): * page/AbstractFrame.h: Added. (WebCore::AbstractFrame::window const): * page/DOMWindow.cpp: (WebCore::DOMWindow::DOMWindow): * page/DOMWindow.h: (isType): * page/Frame.cpp: (WebCore::Frame::window const): (WebCore::Frame::virtualWindow const): * page/Frame.h: (isType): * page/GlobalFrameIdentifier.h: Added. (WebCore::GlobalFrameIdentifier::encode const): (WebCore::GlobalFrameIdentifier::decode): * page/GlobalWindowIdentifier.h: Added. (WebCore::operator==): (WebCore::GlobalWindowIdentifier::hash const): (WebCore::GlobalWindowIdentifier::encode const): (WebCore::GlobalWindowIdentifier::decode): (WTF::GlobalWindowIdentifierHash::hash): (WTF::GlobalWindowIdentifierHash::equal): (WTF::HashTraits<WebCore::GlobalWindowIdentifier>::emptyValue): (WTF::HashTraits<WebCore::GlobalWindowIdentifier>::constructDeletedValue): (WTF::HashTraits<WebCore::GlobalWindowIdentifier>::isDeletedValue): * page/RemoteDOMWindow.cpp: Added. (WebCore::RemoteDOMWindow::RemoteDOMWindow): (WebCore::RemoteDOMWindow::~RemoteDOMWindow): (WebCore::RemoteDOMWindow::self const): (WebCore::RemoteDOMWindow::location const): (WebCore::RemoteDOMWindow::close): (WebCore::RemoteDOMWindow::closed const): (WebCore::RemoteDOMWindow::focus): (WebCore::RemoteDOMWindow::blur): (WebCore::RemoteDOMWindow::length const): (WebCore::RemoteDOMWindow::top const): (WebCore::RemoteDOMWindow::opener const): (WebCore::RemoteDOMWindow::parent const): (WebCore::RemoteDOMWindow::postMessage): The DOM API exposed on RemoteDOMWindow is only the subset of the DOMWindow API that is exposed cross origin, since remote DOMWindow are always from a different origin. The short-term plan is to implement these in a follow-up by relying on IPC (synchronous when necessary) to fetch the information from the real window in the WebProcess where it lives. Longer term, we should probably keep RemoteDOMWindow members in sync with the DOMWindow they're pointing to, so we do not have to rely on synchronous IPC. * page/RemoteDOMWindow.h: Added. (isType): * page/RemoteFrame.cpp: Added. (WebCore::RemoteFrame::RemoteFrame): (WebCore::RemoteFrame::~RemoteFrame): (WebCore::RemoteFrame::virtualWindow const): * page/RemoteFrame.h: Added. (isType): Canonical link: https://commits.webkit.org/200116@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230613 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-04-12 23:55:02 +00:00
/*
* Copyright (C) 2018 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY APPLE INC. AND ITS CONTRIBUTORS ``AS IS''
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
* THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL APPLE INC. OR ITS CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
* THE POSSIBILITY OF SUCH DAMAGE.
*/
#pragma once
#include "AbstractFrame.h"
#include "GlobalFrameIdentifier.h"
#include <wtf/Ref.h>
[Extra zoom mode] Google search results are excessively zoomed in https://bugs.webkit.org/show_bug.cgi?id=185347 <rdar://problem/39999778> Reviewed by Tim Horton. Source/WebCore: It turns out that basing minimum layout size and shrink-to-fit behaviors off of the `shrink-to-fit` viewport argument poses compatibility risks with web pages that already specify `shrink-to-fit` to opt out of default viewport shrinking behaviors in 1/3 multitasking mode on iPad. One way to resolve this is to introduce a new viewport meta content attribute to disable viewport heuristics in extra zoom mode. However, combined shrink-to-fit and minimum device width behaviors are difficult to describe using a single backwards-compatible viewport meta content attribute, and the need to suppress the default behavior of `shrink-to-fit=no` if such an attribute is not disabled further muddles our viewport story. After some internal deliberation, we’ve decided to experiment with a new meta tag named "disabled-adaptations". The content of this meta tag is a comma-separated list of adaptation names; if an adaptation name matches a known adaptation type (for instance, extra zoom mode), we disable the class of behaviors used to adapt web content. The first and only known adaptation type is extra zoom mode, which affects `shrink-to-fit` and layout size adjustments. See per-method changes below for more details. Test: fast/viewport/extrazoom/viewport-disable-extra-zoom-adaptations.html * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * dom/Document.cpp: (WebCore::Document::processDisabledAdaptations): * dom/Document.h: (WebCore::Document::disabledAdaptations const): Add disabled adaptations to Document. Changes to disabled adaptations are not propagated if the parsed disabled adaptation types don't change; upon changing adaptation types, notify the client to adjust for the new disabled adaptations (currently, this only affects the viewport configuration). * dom/ViewportArguments.h: * html/HTMLMetaElement.cpp: (WebCore::HTMLMetaElement::process): * html/parser/HTMLPreloadScanner.cpp: (WebCore::TokenPreloadScanner::StartTagScanner::StartTagScanner): (WebCore::TokenPreloadScanner::StartTagScanner::processAttributes): (WebCore::TokenPreloadScanner::StartTagScanner::processAttribute): * loader/FrameLoader.cpp: (WebCore::FrameLoader::commitProvisionalLoad): Restore the set of disabled adaptations when restoring a page from the cache. * page/Chrome.cpp: (WebCore::Chrome::dispatchDisabledAdaptationsDidChange const): * page/Chrome.h: * page/ChromeClient.h: Add plumbing for changes to the set of disabled adaptations. * page/DisabledAdaptations.cpp: Added. (WebCore::extraZoomModeAdaptationName): * page/DisabledAdaptations.h: Added. Introduce a header containing a new enum for the extra zoom mode adaptation, as well as a helper function to return the extra zoom mode adaptation name. * page/Page.cpp: (WebCore::Page::disabledAdaptations const): Returns the mainframe's set of adaptations to disable. * page/Page.h: * page/RemoteFrame.h: * page/RuntimeEnabledFeatures.h: (WebCore::RuntimeEnabledFeatures::setDisabledAdaptationsMetaTagEnabled): (WebCore::RuntimeEnabledFeatures::disabledAdaptationsMetaTagEnabled const): Add a new runtime feature to gate handling the "disabled-adaptations" meta tag. * page/ViewportConfiguration.cpp: (WebCore::shouldOverrideShrinkToFitArgument): (WebCore::needsUpdateAfterChangingDisabledAdaptations): (WebCore::ViewportConfiguration::setDisabledAdaptations): (WebCore::ViewportConfiguration::shouldOverrideDeviceWidthAndShrinkToFit const): Consult whether or not extra zoom mode adaptations are disabled, instead of the shrink-to-fit attribute value. (WebCore::ViewportConfiguration::updateConfiguration): * page/ViewportConfiguration.h: Add an OptionSet of disabled adaptation types to ViewportConfiguration. Updates to the adaptation type are propagated to the ViewportConfiguration from Document, through the ChromeClient and the client layer (refer to changes in WebKit). Once the OptionSet is changed, we recompute the viewport configuration only if needed by the platform. (WebCore::ViewportConfiguration::viewLayoutSize const): (WebCore::ViewportConfiguration::disabledAdaptations const): * page/WindowFeatures.cpp: (WebCore::parseDisabledAdaptations): * page/WindowFeatures.h: Add a new helper to parse the meta content of a "disabled-adaptations" tag as an OptionSet of disabled adaptation types. The string is parsed by first splitting on the comma character, and then iterating over lower case, whitespace-stripped tokens to look for known adaptation names. So far, only extra zoom mode is supported. * testing/Internals.cpp: (WebCore::Internals::extraZoomModeAdaptationName const): * testing/Internals.h: * testing/Internals.idl: Expose the extra zoom mode adaptation name to the DOM, only when running layout tests. Source/WebKit: Adds a new experimental feature for the "disabled-adaptations" meta tag, and adds plumbing in WebKit to propagate disabled adaptation changes to the ViewportConfiguration. The experimental feature is on by default in extra zoom mode. * Shared/WebPreferences.yaml: * Shared/WebPreferencesDefaultValues.h: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::dispatchDisabledAdaptationsDidChange const): * WebProcess/WebCoreSupport/WebChromeClient.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::disabledAdaptationsDidChange): * WebProcess/WebPage/WebPage.h: Source/WebKitLegacy/ios: Adds a WebKitLegacy method stub for disabled adaptation plumbing. * WebCoreSupport/WebChromeClientIOS.h: * WebCoreSupport/WebChromeClientIOS.mm: (WebChromeClientIOS::dispatchDisabledAdaptationsDidChange const): LayoutTests: Refactor an existing layout test to exercise disabled adaptations in extra zoom mode. * fast/viewport/extrazoom/viewport-change-min-device-width.html: Removed. * fast/viewport/extrazoom/viewport-disable-extra-zoom-adaptations.html: Added. Canonical link: https://commits.webkit.org/201100@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231779 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-05-15 01:07:36 +00:00
#include <wtf/RefPtr.h>
Introduce remote variants of Frame / DOMWindow classes https://bugs.webkit.org/show_bug.cgi?id=184467 <rdar://problem/39011267> Reviewed by Ryosuke Niwa. Introduce remote variants of Frame / DOMWindow classes, for when these frames / windows are hosted on another WebProcess. Those will be used in a follow-up patch. The hierarchy is as follows (class naming will be improved in a follow-up patch to minimise patch size): - AbstractFrame: A frame that can be either local or remote (hosted on another WebProcess) - Frame: A local frame - RemoteFrame: A frame hosted on another WebProcess. A RemoteFrame's window is also remote. - AbstractDOMWindow: A window that be either local or remote (hosted on another WebProcess) - DOMWindow: A local DOMWindow - RemoteDOMWindow: A window hosted on another WebProcess. A RemoteDOMWindow's frame is also remote. A RemoteDOMWindow is always cross-origin. This patch introduces global identifiers (unique across all WebProcesses) for both Frames and Windows. This is useful as we need to know which Frame / DOMWindow a particular RemoteFrame / RemoteDOMWindow is pointing to. Follow-up patch will add support for converting a local DOMWindow / Frame into a remote ones, when a newly opened window (via window.open) is navigated cross-origin (Bug 184515). Other things we'll need to implement in follow-ups: - RemoteDOMWindow will need to know about its opener in order to support the window.opener API. Internally, the opener will be stored as a RemoteFrame so that window.opener always returns the current window in the opener frame (which changes upon navigation). - Nullify a RemoteDOMWindow's frame whenever the window it is pointing to becomes frameless. A frameless window behaves very differently (e.g. very little API is exposed to the Web). This happens when either the newly opened window is either closed or navigated. * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * loader/ContentFilter.cpp: (WebCore::ContentFilter::didDecide): * page/AbstractDOMWindow.cpp: Added. (WebCore::AbstractDOMWindow::AbstractDOMWindow): (WebCore::AbstractDOMWindow::~AbstractDOMWindow): * page/AbstractDOMWindow.h: Added. (WebCore::AbstractDOMWindow::identifier const): * page/AbstractFrame.cpp: Added. (WebCore::AbstractFrame::AbstractFrame): (WebCore::AbstractFrame::~AbstractFrame): * page/AbstractFrame.h: Added. (WebCore::AbstractFrame::window const): * page/DOMWindow.cpp: (WebCore::DOMWindow::DOMWindow): * page/DOMWindow.h: (isType): * page/Frame.cpp: (WebCore::Frame::window const): (WebCore::Frame::virtualWindow const): * page/Frame.h: (isType): * page/GlobalFrameIdentifier.h: Added. (WebCore::GlobalFrameIdentifier::encode const): (WebCore::GlobalFrameIdentifier::decode): * page/GlobalWindowIdentifier.h: Added. (WebCore::operator==): (WebCore::GlobalWindowIdentifier::hash const): (WebCore::GlobalWindowIdentifier::encode const): (WebCore::GlobalWindowIdentifier::decode): (WTF::GlobalWindowIdentifierHash::hash): (WTF::GlobalWindowIdentifierHash::equal): (WTF::HashTraits<WebCore::GlobalWindowIdentifier>::emptyValue): (WTF::HashTraits<WebCore::GlobalWindowIdentifier>::constructDeletedValue): (WTF::HashTraits<WebCore::GlobalWindowIdentifier>::isDeletedValue): * page/RemoteDOMWindow.cpp: Added. (WebCore::RemoteDOMWindow::RemoteDOMWindow): (WebCore::RemoteDOMWindow::~RemoteDOMWindow): (WebCore::RemoteDOMWindow::self const): (WebCore::RemoteDOMWindow::location const): (WebCore::RemoteDOMWindow::close): (WebCore::RemoteDOMWindow::closed const): (WebCore::RemoteDOMWindow::focus): (WebCore::RemoteDOMWindow::blur): (WebCore::RemoteDOMWindow::length const): (WebCore::RemoteDOMWindow::top const): (WebCore::RemoteDOMWindow::opener const): (WebCore::RemoteDOMWindow::parent const): (WebCore::RemoteDOMWindow::postMessage): The DOM API exposed on RemoteDOMWindow is only the subset of the DOMWindow API that is exposed cross origin, since remote DOMWindow are always from a different origin. The short-term plan is to implement these in a follow-up by relying on IPC (synchronous when necessary) to fetch the information from the real window in the WebProcess where it lives. Longer term, we should probably keep RemoteDOMWindow members in sync with the DOMWindow they're pointing to, so we do not have to rely on synchronous IPC. * page/RemoteDOMWindow.h: Added. (isType): * page/RemoteFrame.cpp: Added. (WebCore::RemoteFrame::RemoteFrame): (WebCore::RemoteFrame::~RemoteFrame): (WebCore::RemoteFrame::virtualWindow const): * page/RemoteFrame.h: Added. (isType): Canonical link: https://commits.webkit.org/200116@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230613 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-04-12 23:55:02 +00:00
#include <wtf/TypeCasts.h>
namespace WebCore {
class RemoteDOMWindow;
class RemoteFrame final : public AbstractFrame {
public:
static Ref<RemoteFrame> create(GlobalFrameIdentifier&& frameIdentifier)
{
return adoptRef(* new RemoteFrame(WTFMove(frameIdentifier)));
}
~RemoteFrame();
const GlobalFrameIdentifier& identifier() const { return m_identifier; }
void setWindow(RemoteDOMWindow* window) { m_window = window; }
RemoteDOMWindow* window() const { return m_window; }
Set RemoteDOMWindow's initial opener https://bugs.webkit.org/show_bug.cgi?id=184716 Reviewed by Sam Weinig. Source/WebCore: Add support for WindowProxy type in the IDL. The implementation should return a WindowProxyController and toJS() will take care of converting this into a JSValue via JSDOMWindowProxy. No new tests, rebaselined existing test. * WebCore.xcodeproj/project.pbxproj: * bindings/IDLTypes.h: * bindings/js/JSDOMConvertWindowProxy.h: Added. (WebCore::JSConverter<IDLWindowProxy>::convert): * bindings/js/JSDOMWindowBase.cpp: (WebCore::toJS): * bindings/js/JSDOMWindowBase.h: (WebCore::toJS): * bindings/js/JSDOMWindowProxy.cpp: (WebCore::toJS): (WebCore::toJSDOMWindowProxy): * bindings/js/JSDOMWindowProxy.h: (WebCore::toJS): (WebCore::toJSDOMWindowProxy): * bindings/js/JSRemoteDOMWindowBase.cpp: * bindings/js/JSRemoteDOMWindowBase.h: * bindings/scripts/CodeGenerator.pm: (IsBuiltinType): * bindings/scripts/CodeGeneratorJS.pm: (AddToIncludesForIDLType): (GetBaseIDLType): * page/RemoteDOMWindow.cpp: (WebCore::RemoteDOMWindow::self const): (WebCore::RemoteDOMWindow::top const): (WebCore::RemoteDOMWindow::opener const): (WebCore::RemoteDOMWindow::parent const): * page/RemoteDOMWindow.h: * page/RemoteDOMWindow.idl: * page/RemoteFrame.h: Source/WebKit: When a frame becomes remote, transfer the frame opener from the old frame to the new remote one. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::frameBecameRemote): LayoutTests: Rebaseline existing test now that remoteWindow.opener now returns its initial opener. * http/tests/navigation/process-swap-window-open-expected.txt: Canonical link: https://commits.webkit.org/200270@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230789 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-04-18 22:27:20 +00:00
void setOpener(AbstractFrame* opener) { m_opener = opener; }
AbstractFrame* opener() const { return m_opener.get(); }
Introduce remote variants of Frame / DOMWindow classes https://bugs.webkit.org/show_bug.cgi?id=184467 <rdar://problem/39011267> Reviewed by Ryosuke Niwa. Introduce remote variants of Frame / DOMWindow classes, for when these frames / windows are hosted on another WebProcess. Those will be used in a follow-up patch. The hierarchy is as follows (class naming will be improved in a follow-up patch to minimise patch size): - AbstractFrame: A frame that can be either local or remote (hosted on another WebProcess) - Frame: A local frame - RemoteFrame: A frame hosted on another WebProcess. A RemoteFrame's window is also remote. - AbstractDOMWindow: A window that be either local or remote (hosted on another WebProcess) - DOMWindow: A local DOMWindow - RemoteDOMWindow: A window hosted on another WebProcess. A RemoteDOMWindow's frame is also remote. A RemoteDOMWindow is always cross-origin. This patch introduces global identifiers (unique across all WebProcesses) for both Frames and Windows. This is useful as we need to know which Frame / DOMWindow a particular RemoteFrame / RemoteDOMWindow is pointing to. Follow-up patch will add support for converting a local DOMWindow / Frame into a remote ones, when a newly opened window (via window.open) is navigated cross-origin (Bug 184515). Other things we'll need to implement in follow-ups: - RemoteDOMWindow will need to know about its opener in order to support the window.opener API. Internally, the opener will be stored as a RemoteFrame so that window.opener always returns the current window in the opener frame (which changes upon navigation). - Nullify a RemoteDOMWindow's frame whenever the window it is pointing to becomes frameless. A frameless window behaves very differently (e.g. very little API is exposed to the Web). This happens when either the newly opened window is either closed or navigated. * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * loader/ContentFilter.cpp: (WebCore::ContentFilter::didDecide): * page/AbstractDOMWindow.cpp: Added. (WebCore::AbstractDOMWindow::AbstractDOMWindow): (WebCore::AbstractDOMWindow::~AbstractDOMWindow): * page/AbstractDOMWindow.h: Added. (WebCore::AbstractDOMWindow::identifier const): * page/AbstractFrame.cpp: Added. (WebCore::AbstractFrame::AbstractFrame): (WebCore::AbstractFrame::~AbstractFrame): * page/AbstractFrame.h: Added. (WebCore::AbstractFrame::window const): * page/DOMWindow.cpp: (WebCore::DOMWindow::DOMWindow): * page/DOMWindow.h: (isType): * page/Frame.cpp: (WebCore::Frame::window const): (WebCore::Frame::virtualWindow const): * page/Frame.h: (isType): * page/GlobalFrameIdentifier.h: Added. (WebCore::GlobalFrameIdentifier::encode const): (WebCore::GlobalFrameIdentifier::decode): * page/GlobalWindowIdentifier.h: Added. (WebCore::operator==): (WebCore::GlobalWindowIdentifier::hash const): (WebCore::GlobalWindowIdentifier::encode const): (WebCore::GlobalWindowIdentifier::decode): (WTF::GlobalWindowIdentifierHash::hash): (WTF::GlobalWindowIdentifierHash::equal): (WTF::HashTraits<WebCore::GlobalWindowIdentifier>::emptyValue): (WTF::HashTraits<WebCore::GlobalWindowIdentifier>::constructDeletedValue): (WTF::HashTraits<WebCore::GlobalWindowIdentifier>::isDeletedValue): * page/RemoteDOMWindow.cpp: Added. (WebCore::RemoteDOMWindow::RemoteDOMWindow): (WebCore::RemoteDOMWindow::~RemoteDOMWindow): (WebCore::RemoteDOMWindow::self const): (WebCore::RemoteDOMWindow::location const): (WebCore::RemoteDOMWindow::close): (WebCore::RemoteDOMWindow::closed const): (WebCore::RemoteDOMWindow::focus): (WebCore::RemoteDOMWindow::blur): (WebCore::RemoteDOMWindow::length const): (WebCore::RemoteDOMWindow::top const): (WebCore::RemoteDOMWindow::opener const): (WebCore::RemoteDOMWindow::parent const): (WebCore::RemoteDOMWindow::postMessage): The DOM API exposed on RemoteDOMWindow is only the subset of the DOMWindow API that is exposed cross origin, since remote DOMWindow are always from a different origin. The short-term plan is to implement these in a follow-up by relying on IPC (synchronous when necessary) to fetch the information from the real window in the WebProcess where it lives. Longer term, we should probably keep RemoteDOMWindow members in sync with the DOMWindow they're pointing to, so we do not have to rely on synchronous IPC. * page/RemoteDOMWindow.h: Added. (isType): * page/RemoteFrame.cpp: Added. (WebCore::RemoteFrame::RemoteFrame): (WebCore::RemoteFrame::~RemoteFrame): (WebCore::RemoteFrame::virtualWindow const): * page/RemoteFrame.h: Added. (isType): Canonical link: https://commits.webkit.org/200116@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230613 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-04-12 23:55:02 +00:00
private:
WEBCORE_EXPORT explicit RemoteFrame(GlobalFrameIdentifier&&);
bool isRemoteFrame() const final { return true; }
bool isLocalFrame() const final { return false; }
AbstractDOMWindow* virtualWindow() const final;
GlobalFrameIdentifier m_identifier;
RemoteDOMWindow* m_window { nullptr };
Set RemoteDOMWindow's initial opener https://bugs.webkit.org/show_bug.cgi?id=184716 Reviewed by Sam Weinig. Source/WebCore: Add support for WindowProxy type in the IDL. The implementation should return a WindowProxyController and toJS() will take care of converting this into a JSValue via JSDOMWindowProxy. No new tests, rebaselined existing test. * WebCore.xcodeproj/project.pbxproj: * bindings/IDLTypes.h: * bindings/js/JSDOMConvertWindowProxy.h: Added. (WebCore::JSConverter<IDLWindowProxy>::convert): * bindings/js/JSDOMWindowBase.cpp: (WebCore::toJS): * bindings/js/JSDOMWindowBase.h: (WebCore::toJS): * bindings/js/JSDOMWindowProxy.cpp: (WebCore::toJS): (WebCore::toJSDOMWindowProxy): * bindings/js/JSDOMWindowProxy.h: (WebCore::toJS): (WebCore::toJSDOMWindowProxy): * bindings/js/JSRemoteDOMWindowBase.cpp: * bindings/js/JSRemoteDOMWindowBase.h: * bindings/scripts/CodeGenerator.pm: (IsBuiltinType): * bindings/scripts/CodeGeneratorJS.pm: (AddToIncludesForIDLType): (GetBaseIDLType): * page/RemoteDOMWindow.cpp: (WebCore::RemoteDOMWindow::self const): (WebCore::RemoteDOMWindow::top const): (WebCore::RemoteDOMWindow::opener const): (WebCore::RemoteDOMWindow::parent const): * page/RemoteDOMWindow.h: * page/RemoteDOMWindow.idl: * page/RemoteFrame.h: Source/WebKit: When a frame becomes remote, transfer the frame opener from the old frame to the new remote one. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::frameBecameRemote): LayoutTests: Rebaseline existing test now that remoteWindow.opener now returns its initial opener. * http/tests/navigation/process-swap-window-open-expected.txt: Canonical link: https://commits.webkit.org/200270@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230789 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-04-18 22:27:20 +00:00
RefPtr<AbstractFrame> m_opener;
Introduce remote variants of Frame / DOMWindow classes https://bugs.webkit.org/show_bug.cgi?id=184467 <rdar://problem/39011267> Reviewed by Ryosuke Niwa. Introduce remote variants of Frame / DOMWindow classes, for when these frames / windows are hosted on another WebProcess. Those will be used in a follow-up patch. The hierarchy is as follows (class naming will be improved in a follow-up patch to minimise patch size): - AbstractFrame: A frame that can be either local or remote (hosted on another WebProcess) - Frame: A local frame - RemoteFrame: A frame hosted on another WebProcess. A RemoteFrame's window is also remote. - AbstractDOMWindow: A window that be either local or remote (hosted on another WebProcess) - DOMWindow: A local DOMWindow - RemoteDOMWindow: A window hosted on another WebProcess. A RemoteDOMWindow's frame is also remote. A RemoteDOMWindow is always cross-origin. This patch introduces global identifiers (unique across all WebProcesses) for both Frames and Windows. This is useful as we need to know which Frame / DOMWindow a particular RemoteFrame / RemoteDOMWindow is pointing to. Follow-up patch will add support for converting a local DOMWindow / Frame into a remote ones, when a newly opened window (via window.open) is navigated cross-origin (Bug 184515). Other things we'll need to implement in follow-ups: - RemoteDOMWindow will need to know about its opener in order to support the window.opener API. Internally, the opener will be stored as a RemoteFrame so that window.opener always returns the current window in the opener frame (which changes upon navigation). - Nullify a RemoteDOMWindow's frame whenever the window it is pointing to becomes frameless. A frameless window behaves very differently (e.g. very little API is exposed to the Web). This happens when either the newly opened window is either closed or navigated. * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * loader/ContentFilter.cpp: (WebCore::ContentFilter::didDecide): * page/AbstractDOMWindow.cpp: Added. (WebCore::AbstractDOMWindow::AbstractDOMWindow): (WebCore::AbstractDOMWindow::~AbstractDOMWindow): * page/AbstractDOMWindow.h: Added. (WebCore::AbstractDOMWindow::identifier const): * page/AbstractFrame.cpp: Added. (WebCore::AbstractFrame::AbstractFrame): (WebCore::AbstractFrame::~AbstractFrame): * page/AbstractFrame.h: Added. (WebCore::AbstractFrame::window const): * page/DOMWindow.cpp: (WebCore::DOMWindow::DOMWindow): * page/DOMWindow.h: (isType): * page/Frame.cpp: (WebCore::Frame::window const): (WebCore::Frame::virtualWindow const): * page/Frame.h: (isType): * page/GlobalFrameIdentifier.h: Added. (WebCore::GlobalFrameIdentifier::encode const): (WebCore::GlobalFrameIdentifier::decode): * page/GlobalWindowIdentifier.h: Added. (WebCore::operator==): (WebCore::GlobalWindowIdentifier::hash const): (WebCore::GlobalWindowIdentifier::encode const): (WebCore::GlobalWindowIdentifier::decode): (WTF::GlobalWindowIdentifierHash::hash): (WTF::GlobalWindowIdentifierHash::equal): (WTF::HashTraits<WebCore::GlobalWindowIdentifier>::emptyValue): (WTF::HashTraits<WebCore::GlobalWindowIdentifier>::constructDeletedValue): (WTF::HashTraits<WebCore::GlobalWindowIdentifier>::isDeletedValue): * page/RemoteDOMWindow.cpp: Added. (WebCore::RemoteDOMWindow::RemoteDOMWindow): (WebCore::RemoteDOMWindow::~RemoteDOMWindow): (WebCore::RemoteDOMWindow::self const): (WebCore::RemoteDOMWindow::location const): (WebCore::RemoteDOMWindow::close): (WebCore::RemoteDOMWindow::closed const): (WebCore::RemoteDOMWindow::focus): (WebCore::RemoteDOMWindow::blur): (WebCore::RemoteDOMWindow::length const): (WebCore::RemoteDOMWindow::top const): (WebCore::RemoteDOMWindow::opener const): (WebCore::RemoteDOMWindow::parent const): (WebCore::RemoteDOMWindow::postMessage): The DOM API exposed on RemoteDOMWindow is only the subset of the DOMWindow API that is exposed cross origin, since remote DOMWindow are always from a different origin. The short-term plan is to implement these in a follow-up by relying on IPC (synchronous when necessary) to fetch the information from the real window in the WebProcess where it lives. Longer term, we should probably keep RemoteDOMWindow members in sync with the DOMWindow they're pointing to, so we do not have to rely on synchronous IPC. * page/RemoteDOMWindow.h: Added. (isType): * page/RemoteFrame.cpp: Added. (WebCore::RemoteFrame::RemoteFrame): (WebCore::RemoteFrame::~RemoteFrame): (WebCore::RemoteFrame::virtualWindow const): * page/RemoteFrame.h: Added. (isType): Canonical link: https://commits.webkit.org/200116@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230613 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-04-12 23:55:02 +00:00
};
} // namespace WebCore
SPECIALIZE_TYPE_TRAITS_BEGIN(WebCore::RemoteFrame)
static bool isType(const WebCore::AbstractFrame& frame) { return frame.isRemoteFrame(); }
SPECIALIZE_TYPE_TRAITS_END()