| commit | 13bbad51ef870160c31bef035b6b126a3ae231cb | [log] [tgz] |
|---|---|---|
| author | Mario Sanchez Prada <[email protected]> | Mon Jun 01 18:12:29 2020 |
| committer | Commit Bot <[email protected]> | Mon Jun 01 18:12:29 2020 |
| tree | 227edd1f2df9eb213b6e94493541854fabc7791b | |
| parent | 51f0f2ba3eea9eda6290b5499f80e5f920bf2a08 [diff] |
Reland "Migrate FrameMsg_GetSerializedHtmlWithLocalLinks to mojom::Frame" This is a reland of bcb3ba73193bf4a48017e5c391c62ce29165bb21 This CL migrates the messages FrameMsg_GetSerializedHtmlWithLocalLinks and FrameHostMsg_GetSerializedHtmlWithLocalLinksResponse messages as a single mojom.Frame.GetSerializedHtmlWithLocalLinks() mojo method that accepts a pending remote to a newly added interface providing the two callbacks needed to report on the data chunks being serialized and when when the process is over (FrameHTMLSerializerWithLocalLinksCallbacks). This is necessary to deal with the fact that multiple responses can be sent from the renderer to the browser process for a single serialization process, which is the use case that produced a crash with the previous version of this migration (crrev.com/c/2207234 and crbug.com/1085721). Last, this CL also adds a new unit test to the SavePageBrowserTest test suite (i.e. SaveHTMLWithLongTextContent) to make sure that we explicitly cover the situation that caused the crash, that is, when we attempt to serialize HTML content with more than 65536 bytes of data, see WebFrameSerializerImpl::EncodeAndFlushBuffer(). Original change's description: > Migrate FrameMsg_GetSerializedHtmlWithLocalLinks to mojom::Frame > > This CL moves this message out of frame_messages.h and adds a new > method in content::mojom::Frame to allow the browser request from > the renderer the serialization of a RenderFrame's contents, regardless > of whether such contents include same-site or cross-site resources. > > Since this functionality also requires an asynchronous response from > the renderer once the serialization is complete, this CL does also > migrate FrameHostMsg_SerializedHtmlWithLocalLinksResponse, for which > some extra bit have been added to WebFrameSerializer[Client], so that > we can appropriately reply to the browser process when the serialized > data is available. > > In a future CL, this functionality will probably get moved down into > Blink itself, but at the moment there's way too much functionality > in use in Blink's public API, so this CL does not tackle that part > yet, and focused on the migration from legacy IPC to mojo only. > > Bug: 1044088 > Change-Id: I4ce5b3cfe795e5019bb30a278577ec2be3ee2854 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2207234 > Commit-Queue: Mario Sanchez Prada <[email protected]> > Reviewed-by: Kentaro Hara <[email protected]> > Reviewed-by: Aaron Colwell <[email protected]> > Reviewed-by: Kinuko Yasuda <[email protected]> > Cr-Commit-Position: refs/heads/master@{#770794} Bug: 1044088, 1085721 Change-Id: Ia9ab65632194a0bcfd0c5d6fc8ce57d60fc5e271 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2214890 Commit-Queue: Mario Sanchez Prada <[email protected]> Reviewed-by: Kentaro Hara <[email protected]> Reviewed-by: Kinuko Yasuda <[email protected]> Reviewed-by: Aaron Colwell <[email protected]> Cr-Commit-Position: refs/heads/master@{#773730}
ChromiumChromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web.
The project's web site is https://www.chromium.org.
Documentation in the source is rooted in docs/README.md.
Learn how to Get Around the Chromium Source Code Directory Structure .
For historical reasons, there are some small top level directories. Now the guidance is that new top level directories are for product (e.g. Chrome, Android WebView, Ash). Even if these products have multiple executables, the code should be in subdirectories of the product.