summaryrefslogtreecommitdiffstats
path: root/content/renderer/web_frame_utils.h
Commit message (Collapse)AuthorAgeFilesLines
* OOPIFs: Transitioning MHTML generation from view-oriented to frame-oriented.lukasza2015-12-141-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IPC Messages ============ This CL replaces the following view-oriented IPC messages: IPC_MESSAGE_ROUTED2(ViewMsg_SavePageAsMHTML, int /* job_id */, IPC::PlatformFileForTransit /* file handle */) IPC_MESSAGE_CONTROL2(ViewHostMsg_SavedPageAsMHTML, int /* job_id */, int64 /* size of the MHTML file, -1 if error */) with the following frame-oriented IPC messages: IPC_MESSAGE_ROUTED5(FrameMsg_SerializeAsMHTML, int /* job_id (used to match responses to requests) */, IPC::PlatformFileForTransit /* destination file */, std::string /* mhtml boundary marker */, FrameRoutingIdToContentIdMap, bool /* is last frame */) IPC_MESSAGE_ROUTED3(FrameHostMsg_SerializeAsMHTMLResponse, int /* job_id (used to match responses to requests) */, bool /* true if success, false if error */, std::string /* mhtml boundary marker that was used */) This allows MHTML generation to work, even when some frames are in separate processes. Supporting changes ================== This CL builds on top of recent CLs below: crrev.com/1436683002 - Making PageSerializer operate on single frames only. crrev.com/1441553002 - Generating CIDs in Blink during MHTML serialization. crrev.com/1415463007 - Exposing more granular methods from MHTMLArchive. crrev.com/1380963006 - MHTMLGenerator preparation for per-frame serialization. Handling of renderer IPC messages was moved from MHTMLGenerator into RenderFrameImpl. Handling of browser IPC responses was moved from RenderProcessHostImpl into RenderFrameHostImpl. MHTMLGenerationManager now handles walking over all the frames and asking the renderer process to serialize them into MHTML (sequentially - one frame at a time). MHTMLGenerationManager also handles generating ContentIDs for all frames. BUG=538766 Review URL: https://codereview.chromium.org/1386873003 Cr-Commit-Position: refs/heads/master@{#365082}
* Vector-of-structs (instead of struct-of-vectors) in "savable resources" IPC.lukasza2015-11-041-0/+20
It is cleaner to send a vector-of-structs rather than a struct-of-vectors (i.e. no need to verify the size of the vectors is the same, iteration is easier as it doesn't require an index to look into both vectors). This CL changes how "subframes" are sent in FrameHostMsg_SavableResourceLinksResponse. They used to be sent as 2 vectors (of URLs and of routing_ids) and now they are sent as a single vector (of a struct that contains URLs and routing_ids). The same struct (content::SavableSubframe) is reused to return results out of GetSavableResourceLinksForFrame in savable_resources.cc. The decision to reuse the same struct necessitates 1) sharing/reusing GetRoutingIdForFrameOrProxy across render_frame_impl.cc and savable_resources.cc and (so GetRoutingIdForFrameOrProxy has been moved to web_frame_utils compilation unit) 2) introducing a content::SavableSubframe struct that can be shared via A) IPC handlers in browser and renderer and B) by savable_resources.cc (and addressing B seemed better with an explicit struct with a short name, rather than introducing an implicit struct via IPC_STRUCT_BEGIN). Note that this CL keeps using a struct-of-vectors for reporting savable resources (URL + referrer). This will be addressed in a separate CL (crrev.com/1425013004). BUG=526786 Review URL: https://codereview.chromium.org/1422473004 Cr-Commit-Position: refs/heads/master@{#357852}