Move the writing of the MHTML footer to the browser process.

third_party/WebKit/public/web/WebFrameSerializer.h

Index: third_party/WebKit/public/web/WebFrameSerializer.h
diff --git a/third_party/WebKit/public/web/WebFrameSerializer.h b/third_party/WebKit/public/web/WebFrameSerializer.h
index 38ce57ac7f833521e2756aeacc92ccc8f0910f70..ebf6dde0965505eb80d3c975dafe4f04345965bc 100644
--- a/third_party/WebKit/public/web/WebFrameSerializer.h
+++ b/third_party/WebKit/public/web/WebFrameSerializer.h
@@ -95,14 +95,6 @@ class WebFrameSerializer {
       WebLocalFrame*,
       MHTMLPartsGenerationDelegate*);
 
-  // Generates and returns an MHTML footer.
-  //
-  // Same |boundary| needs to used for all generateMHTMLHeader and
-  // generateMHTMLParts and generateMHTMLFooter calls that belong to the same
-  // MHTML document (see also rfc1341, section 7.2.1, "boundary" description).
-  BLINK_EXPORT static WebThreadSafeData generateMHTMLFooter(
-      const WebString& boundary);

[dcheng, 2017/03/09 01:56:51]

For symmetry, it would be nice to remove generateMHTMLHeader() from the public
API as well. Would it be possible to do that in a followup?

[carlosk, 2017/03/09 22:03:36]

I am still considering it (you can see it mentioned in the referred issue). Even
though I appreciate the symmetry aspect the header requires more data and more
tooling on that I still have to figure out I can practically obtain/use from
inside content/.

[dcheng, 2017/03/09 22:08:46]

My concern is that the interaction between Blink and content for page
serialization is already very complicated, and not having a consistent interface
will be a long-term maintenance burden. The dependencies on title and mime type
should both be satisfiable from content: WebDocument has a title getter, and the
WebDataSource of the frame points to the response, which has an associated MIME
type.

[carlosk, 2017/03/09 23:07:29]

Acknowledged.

[dcheng, 2017/03/09 23:09:17]

To clarify, does that mean you'll be investigating now or in a followup? If it's
a followup, do you mind filing a bug and adding a TODO so we don't lose track of
this?

[carlosk, 2017/03/09 23:13:45]

Not now. I will keep the linked issue (https://crbug.com/672292) open anyway
until I look into that.

-
   // IMPORTANT:
   // The API below is an older implementation of frame serialization that
   // will be removed soon.