The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/27fa065af52591c67adba826584ff854beaa0a35

commit 27fa065af52591c67adba826584ff854beaa0a35
Author: carlosk <carlosk@chromium.org>
Date: Wed Oct 05 23:10:36 2016

Move MHTML file writing out of the renderer main thread.

This change moves the step of writing MHTML serialized and encoded data
to file out of the renderer main thread, into its FILE thread. The less
we block the main one, the more responsive the renderer remains which is
good.

Note: I mande a correction to the logic tracked by the UMA histogram
PageSerialization.MhtmlGeneration.WriteToDiskTime.SingleFrame to make sure
it includes the file close operation that might involve a buffer flush
that could be significant.

BUG= 651525 , 645686 

Review-Url: https://codereview.chromium.org/2379823003
Cr-Commit-Position: refs/heads/master@{#423331}

[modify] https://crrev.com/27fa065af52591c67adba826584ff854beaa0a35/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/27fa065af52591c67adba826584ff854beaa0a35/content/renderer/render_frame_impl.h
[modify] https://crrev.com/27fa065af52591c67adba826584ff854beaa0a35/third_party/WebKit/Source/platform/mhtml/MHTMLArchive.cpp
[modify] https://crrev.com/27fa065af52591c67adba826584ff854beaa0a35/third_party/WebKit/Source/platform/mhtml/MHTMLArchive.h
[modify] https://crrev.com/27fa065af52591c67adba826584ff854beaa0a35/third_party/WebKit/Source/web/WebFrameSerializer.cpp
[modify] https://crrev.com/27fa065af52591c67adba826584ff854beaa0a35/third_party/WebKit/Source/web/tests/MHTMLTest.cpp
[modify] https://crrev.com/27fa065af52591c67adba826584ff854beaa0a35/third_party/WebKit/public/web/WebFrameSerializer.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f72e2c5e69ca7a44db46622e96f2eaab2849d70a

commit f72e2c5e69ca7a44db46622e96f2eaab2849d70a
Author: carlosk <carlosk@chromium.org>
Date: Sat Oct 08 01:05:31 2016

MHTML saving optimization: don't generate CSS code that will be discarded.

FrameSerializer::serializeCSSStyleSheet code was generating CSS code for
all style elements in a frame even if they were already included in the
main HTML body generation executed earlier on in
FrameSerializer::serializeFrame. This generated code was simply
discarded later on.

This change detects early on if generating the CSS code will be really needed
and skips it if not. Also, when the CSS can be uniquely identified by its URL
and that URL was already analyzed before the method simply returns.

Tests on a Samsung Galaxy J1 loading a CSS-heavy web page [1] showed roughly
40% less CSS code generated and 20% less accumulative time taken from all
render processes' main threads for the whole save operation.

[1] http://www.creativebloq.com/web-design/examples-css-912710

BUG= 651525 

Review-Url: https://codereview.chromium.org/2397983002
Cr-Commit-Position: refs/heads/master@{#424032}

[modify] https://crrev.com/f72e2c5e69ca7a44db46622e96f2eaab2849d70a/third_party/WebKit/Source/core/frame/FrameSerializer.cpp

I'd like to request merging both last changes above:
- 27fa065af52591c67adba826584ff854beaa0a35 in comment #1
- f72e2c5e69ca7a44db46622e96f2eaab2849d70a in comment #2

They are important optimizations for Offline Page Caching to be able to be enabled as a feature.

Your change meets the bar and is auto-approved for M55 (branch: 2883)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5453db5beff03a09ad40a2b704dd4b40b8273015

commit 5453db5beff03a09ad40a2b704dd4b40b8273015
Author: Carlos Knippschild <carlosk@chromium.org>
Date: Tue Oct 11 18:36:54 2016

MHTML saving optimization: don't generate CSS code that will be discarded.

FrameSerializer::serializeCSSStyleSheet code was generating CSS code for
all style elements in a frame even if they were already included in the
main HTML body generation executed earlier on in
FrameSerializer::serializeFrame. This generated code was simply
discarded later on.

This change detects early on if generating the CSS code will be really needed
and skips it if not. Also, when the CSS can be uniquely identified by its URL
and that URL was already analyzed before the method simply returns.

Tests on a Samsung Galaxy J1 loading a CSS-heavy web page [1] showed roughly
40% less CSS code generated and 20% less accumulative time taken from all
render processes' main threads for the whole save operation.

[1] http://www.creativebloq.com/web-design/examples-css-912710

BUG= 651525 

Review-Url: https://codereview.chromium.org/2397983002
Cr-Commit-Position: refs/heads/master@{#424032}
(cherry picked from commit f72e2c5e69ca7a44db46622e96f2eaab2849d70a)

Review URL: https://codereview.chromium.org/2411853002 .

Cr-Commit-Position: refs/branch-heads/2883@{#38}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/5453db5beff03a09ad40a2b704dd4b40b8273015/third_party/WebKit/Source/core/frame/FrameSerializer.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/27fa065af52591c67adba826584ff854beaa0a35

commit 27fa065af52591c67adba826584ff854beaa0a35
Author: carlosk <carlosk@chromium.org>
Date: Wed Oct 05 23:10:36 2016

Move MHTML file writing out of the renderer main thread.

This change moves the step of writing MHTML serialized and encoded data
to file out of the renderer main thread, into its FILE thread. The less
we block the main one, the more responsive the renderer remains which is
good.

Note: I mande a correction to the logic tracked by the UMA histogram
PageSerialization.MhtmlGeneration.WriteToDiskTime.SingleFrame to make sure
it includes the file close operation that might involve a buffer flush
that could be significant.

BUG= 651525 , 645686 

Review-Url: https://codereview.chromium.org/2379823003
Cr-Commit-Position: refs/heads/master@{#423331}

[modify] https://crrev.com/27fa065af52591c67adba826584ff854beaa0a35/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/27fa065af52591c67adba826584ff854beaa0a35/content/renderer/render_frame_impl.h
[modify] https://crrev.com/27fa065af52591c67adba826584ff854beaa0a35/third_party/WebKit/Source/platform/mhtml/MHTMLArchive.cpp
[modify] https://crrev.com/27fa065af52591c67adba826584ff854beaa0a35/third_party/WebKit/Source/platform/mhtml/MHTMLArchive.h
[modify] https://crrev.com/27fa065af52591c67adba826584ff854beaa0a35/third_party/WebKit/Source/web/WebFrameSerializer.cpp
[modify] https://crrev.com/27fa065af52591c67adba826584ff854beaa0a35/third_party/WebKit/Source/web/tests/MHTMLTest.cpp
[modify] https://crrev.com/27fa065af52591c67adba826584ff854beaa0a35/third_party/WebKit/public/web/WebFrameSerializer.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5453db5beff03a09ad40a2b704dd4b40b8273015

commit 5453db5beff03a09ad40a2b704dd4b40b8273015
Author: Carlos Knippschild <carlosk@chromium.org>
Date: Tue Oct 11 18:36:54 2016

MHTML saving optimization: don't generate CSS code that will be discarded.

FrameSerializer::serializeCSSStyleSheet code was generating CSS code for
all style elements in a frame even if they were already included in the
main HTML body generation executed earlier on in
FrameSerializer::serializeFrame. This generated code was simply
discarded later on.

This change detects early on if generating the CSS code will be really needed
and skips it if not. Also, when the CSS can be uniquely identified by its URL
and that URL was already analyzed before the method simply returns.

Tests on a Samsung Galaxy J1 loading a CSS-heavy web page [1] showed roughly
40% less CSS code generated and 20% less accumulative time taken from all
render processes' main threads for the whole save operation.

[1] http://www.creativebloq.com/web-design/examples-css-912710

BUG= 651525 

Review-Url: https://codereview.chromium.org/2397983002
Cr-Commit-Position: refs/heads/master@{#424032}
(cherry picked from commit f72e2c5e69ca7a44db46622e96f2eaab2849d70a)

Review URL: https://codereview.chromium.org/2411853002 .

Cr-Commit-Position: refs/branch-heads/2883@{#38}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/5453db5beff03a09ad40a2b704dd4b40b8273015/third_party/WebKit/Source/core/frame/FrameSerializer.cpp

[Automated comment] removing mislabelled merge-merged-2840

This was more of an umbrella task for MHTML generation optimizations. As the remained, envisioned changes are already reported as separate issues -- here marked as blocking -- I'll go ahead and mark this one fixed.