cef/libcef/renderer/render_frame_util.cc

55 lines
1.9 KiB
C++
Raw Normal View History

// Copyright (c) 2012 The Chromium Embedded Framework Authors.
// Portions copyright (c) 2011 The Chromium Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
#include "libcef/renderer/render_frame_util.h"
Move message routing from CefBrowser to CefFrame (see issue #2498). This change moves the SendProcessMessage method from CefBrowser to CefFrame and adds CefBrowser parameters to OnProcessMessageReceived and OnDraggableRegionsChanged. The internal implementation has changed as follows: - Frame IDs are now a 64-bit combination of the 32-bit render_process_id and render_routing_id values that uniquely identify a RenderFrameHost (RFH). - CefFrameHostImpl objects are now managed by CefBrowserInfo with life span tied to RFH expectations. Specifically, a CefFrameHostImpl object representing a sub-frame will be created when a RenderFrame is created in the renderer process and detached when the associated RenderFrame is deleted or the renderer process in which it runs has died. - The CefFrameHostImpl object representing the main frame will always be valid but the underlying RFH (and associated frame ID) may change over time as a result of cross-origin navigations. Despite these changes calling LoadURL on the main frame object in the browser process will always navigate as expected. - Speculative RFHs, which may be created as a result of a cross-origin navigation and discarded if that navigation is not committed, are now handled correctly (e.g. ignored in most cases until they're committed). - It is less likely, but still possible, to receive a CefFrame object with an invalid frame ID (ID < 0). This can happen in cases where a RFH has not yet been created for a sub-frame. For example, when OnBeforeBrowse is called before initiating navigation in a previously nonexisting sub-frame. To test: All tests pass with NetworkService enabled and disabled.
2019-05-24 22:23:43 +02:00
#include "libcef/common/frame_util.h"
#include "libcef/renderer/blink_glue.h"
#include "base/logging.h"
#include "content/public/renderer/render_thread.h"
#include "content/renderer/render_frame_impl.h"
#include "third_party/blink/public/web/web_local_frame.h"
namespace render_frame_util {
std::string GetIdentifier(blink::WebLocalFrame* frame) {
// Each WebFrame will have an associated RenderFrame. The RenderFrame
// routing IDs are unique within a given renderer process.
return frame_util::MakeFrameIdentifier(content::GlobalRenderFrameHostToken(
content::RenderThread::Get()->GetClientId(),
frame->GetLocalFrameToken()));
}
std::string GetName(blink::WebLocalFrame* frame) {
DCHECK(frame);
// Return the assigned name if it is non-empty. This represents the name
// property on the frame DOM element. If the assigned name is empty, revert to
Move message routing from CefBrowser to CefFrame (see issue #2498). This change moves the SendProcessMessage method from CefBrowser to CefFrame and adds CefBrowser parameters to OnProcessMessageReceived and OnDraggableRegionsChanged. The internal implementation has changed as follows: - Frame IDs are now a 64-bit combination of the 32-bit render_process_id and render_routing_id values that uniquely identify a RenderFrameHost (RFH). - CefFrameHostImpl objects are now managed by CefBrowserInfo with life span tied to RFH expectations. Specifically, a CefFrameHostImpl object representing a sub-frame will be created when a RenderFrame is created in the renderer process and detached when the associated RenderFrame is deleted or the renderer process in which it runs has died. - The CefFrameHostImpl object representing the main frame will always be valid but the underlying RFH (and associated frame ID) may change over time as a result of cross-origin navigations. Despite these changes calling LoadURL on the main frame object in the browser process will always navigate as expected. - Speculative RFHs, which may be created as a result of a cross-origin navigation and discarded if that navigation is not committed, are now handled correctly (e.g. ignored in most cases until they're committed). - It is less likely, but still possible, to receive a CefFrame object with an invalid frame ID (ID < 0). This can happen in cases where a RFH has not yet been created for a sub-frame. For example, when OnBeforeBrowse is called before initiating navigation in a previously nonexisting sub-frame. To test: All tests pass with NetworkService enabled and disabled.
2019-05-24 22:23:43 +02:00
// the internal unique name. This matches the logic in
// CefFrameHostImpl::RefreshAttributes.
if (frame->AssignedName().length() > 0) {
return frame->AssignedName().Utf8();
}
content::RenderFrameImpl* render_frame =
content::RenderFrameImpl::FromWebFrame(frame);
DCHECK(render_frame);
2023-01-02 23:59:03 +01:00
if (render_frame) {
return render_frame->unique_name();
2023-01-02 23:59:03 +01:00
}
return std::string();
}
std::optional<blink::LocalFrameToken> ParseFrameTokenFromIdentifier(
const std::string& identifier) {
const auto& global_token = frame_util::ParseFrameIdentifier(identifier);
if (!global_token ||
global_token->child_id != content::RenderThread::Get()->GetClientId()) {
return std::nullopt;
}
return global_token->frame_token;
}
} // namespace render_frame_util