Move MHTML file writing out of the renderer main thread.

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 eb1a3ae8b0aee9757ca7fdfe18566ab84f6ca0bf..11b35fed7e5827665828e2e3d98f79e0ff6d23f6 100644
--- a/third_party/WebKit/public/web/WebFrameSerializer.h
+++ b/third_party/WebKit/public/web/WebFrameSerializer.h
@@ -37,6 +37,7 @@
 #include "../platform/WebURL.h"
 #include "../platform/WebVector.h"
 #include "WebFrameSerializerCacheControlPolicy.h"
+#include <vector>
 
 namespace blink {
 
@@ -77,7 +78,7 @@ class WebFrameSerializer {
   // 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 WebData generateMHTMLHeader(
+  BLINK_EXPORT static std::vector<char> generateMHTMLHeader(

[dcheng, 2016/10/04 04:34:48]

We don't allow STL containers (string, vector, map, etc) in the public headers.
Similarly, we also don't use STL inside Blink currently.

Historical background can be found at
https://lists.webkit.org/pipermail/webkit-dev/2008-January/003100.html

In order to use STL containers in Blink, at least several things need
investigation:
- Performance: someone needs to measure if the STL equivalent to the WTF version
is just as performant. There are anecdotes that the WTF versions are a perf win,
but IIRC, no one has measured recently.
- Consistency: if there are perf issues, it's easier to have consistent rules
and just not allow STL containers
- Codegen: On some platforms, std::string is actually COW and inlines a ton of
code. Someone needs to demonstrate that the STL versions are no worse than the
WTF versions (and ideally better)

So unfortunately, this will have to use WebData or WebThreadSafeData, if we need
to pass between threads.

* You'll see some usage in tests, but that's about it.

       const WebString& boundary,
       WebLocalFrame*,
       MHTMLPartsGenerationDelegate*);
@@ -88,16 +89,18 @@ class WebFrameSerializer {
   // 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 WebData generateMHTMLParts(const WebString& boundary,
-                                                 WebLocalFrame*,
-                                                 MHTMLPartsGenerationDelegate*);
+  BLINK_EXPORT static std::vector<char> generateMHTMLParts(
+      const WebString& boundary,
+      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 WebData generateMHTMLFooter(const WebString& boundary);
+  BLINK_EXPORT static std::vector<char> generateMHTMLFooter(
+      const WebString& boundary);
 
   // IMPORTANT:
   // The API below is an older implementation of frame serialization that