The PDF loading documentation in extension_system.cc has be updated to
describe the new code paths.
To support delivery of input events to the mime handler renderer process it is
now necessary to route events via the correct RWHV interface. For Aura-based
platforms (Windows/Linux) this means RWHVAura::On*Event and for macOS this
means RWHVMac::RouteOrProcess*Event. Since Aura uses UI event types these have
become the source of truth on Aura-based platforms with conversion to Web event
types when needed (primarily for OSR).
This change also adds a timeout for CefProcessHostMsg_GetNewBrowserInfo to
avoid a hung renderer process if the guest WebContents route is not
registered via CefMimeHandlerViewGuestDelegate::OnGuestDetached as expected
prior to CefBrowserInfoManager::OnGetNewBrowserInfo being called. This
timeout can be disabled for testing purposes by passing the
`--disable-new-browser-info-timeout` command-line flag.
The `--disable-features=MimeHandlerViewInCrossProcessFrame` command-line
flag can be used for a limited time to restore the previous implementation
based on BrowserPlugin. That implementation will be deleted starting with
the 3897 branch update.
Known issues:
- ExecuteJavaScript calls on the frame hosting the PDF extension will not
be routed to the mime handler renderer process.
- The PDF extension will not load successfully if blocked by
ChromePluginPlaceholder and then manually continued via the "Run this
plugin" context menu option (see https://crbug.com/533069#c41).
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.
Requests created using CefURLRequest::Create are not associated with a
browser/frame. When originating from the render process these requests cannot be
intercepted and consequently only http(s) and blob requests are supported. To
work around this limitation a new CefFrame::CreateURLRequest method has been
added that allows the request to be associated with that browser/frame for
interception purposes.
This change also fixes an issue with the NetworkService implementation where
redirected requests could result in two parallel requests being sent to the
target server.
To test: URLRequestTest.* tests pass with NetworkService enabled.
The optional |extra_info| parameter provides an opportunity to specify extra
information specific to the created browser that will be passed to
CefRenderProcessHandler::OnBrowserCreated() in the render process.
- The |category| value for all TRACE calls from CEF client applications is now
"cef.client" due to https://crrev.com/331266377d.
- The |with_menu_marker| parameter to CreateMenuButton has been removed due to
https://crrev.com/7f7e382118.
Known issues:
- The CefLoadCRLSetsFile function needs to be re-implemented (see issue #2497).
- Linux: GTK2 support has been removed. The cefclient sample needs to be updated
to use GTK3 (see issue #2014).
- Remove |accept_lang| parameter from CefJSDialogHandler::OnJSDialog
and CefFormatUrlForSecurityDisplay (see https://crbug.com/336973#c36).
- Remove remaining NPAPI-related code including functions from
cef_web_plugin.h (see https://crbug.com/493212#c55).
- Mac: 10.7+ deployment target is now required for client applications.
- Mac: Remove CefBrowserHost::SetWindowVisibility (issue #1375). No
replacement is required for windowed rendering. Use WasHidden for
off-screen rendering.
- Windows: Visual Studio 2015 Update 2 is now required when building
CEF/Chromium.
- Delete include/cef_runnable.h (issue #1336).
- Build the cef_unittests target using all Chromium headers. Add a
USING_CHROMIUM_INCLUDES define and libcef_dll_wrapper_unittests
target to support this. This change avoids compile errors due to
the divergence of CEF and Chromium base/ header implementations.
The libcef_dll_wrapper sources must now compile successfully with
both CEF and Chromium base/ headers (issue #1632).
- The onbeforeunload message specified via JavaScript is no longer
passed to the client (see http://crbug.com/587940).
- Building on Windows now requires the Windows 10.0.10586 SDK.
- Remove CefParseCSSColor which was implemented using Blink code in the
browser process. This is longer advisable now that the Oilpan GC is enabled.
- Avoid potential renderer process crashes by disabling script actions
on the CefV8Context passed to CefRenderProcessHandler::OnContextReleased.
Marshall Greenblatt
Alexander Guettler
Daniel Nitsche
Ananyo Maiti
Petra Öhlin
cef-ms
Chris Dziemborowicz