I can reproduce this locally. I reverted 7521deccbb7d3d4a7700e6e007e679a8706d8be0 and the timeout stopped.

patch: 7521deccbb7d3d4a7700e6e007e679a8706d8be0
Transmit the response's body datapipe in CommitNavigation().

Here are some that recently went flaky for timeout reasons:
fast/history/history-back-initial-vs-final-url.html ( Code Search ):
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fast%2Fhistory%2Fhistory-back-initial-vs-final-url.html&testType=webkit_layout_tests

http/tests/history/back-to-post.html ( Code Search )
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=http%2Ftests%2Fhistory%2Fback-to-post.html&testType=webkit_layout_tests

I think the following failures may also be related:
http/tests/history/redirect-js-form-submit-0-seconds.html ( Code Search )
http/tests/history/redirect-js-location-assign-0-seconds.html ( Code Search )
http/tests/misc/resource-timing-iframe-restored-from-history.html ( Code Search )
http/tests/navigation/back-send-referrer.html ( Code Search )
http/tests/security/xssAuditor/object-src-inject.html ( Code Search )
scrollbars/resize-scales-with-dpi-150.html ( Code Search )
svg/animations/dynamic-modify-transform-without-baseval.html ( Code Search )
virtual/layout_ng_experimental/fast/multicol/paged-becomes-multicol-auto-height.html ( Code Search )
virtual/prefer_compositing_to_lcd_text/scrollbars/resize-scales-with-dpi-150.html ( Code Search )
virtual/stable/http/tests/navigation/back-send-referrer.html ( Code Search )

I just synced to tip-of-tree and now I cannot reproduce the timeouts. I'm going to hold off on reverting until I am more sure.

I can reliably reproduce a failure on fast/history/history-back-initial-vs-final-url.html after 7521deccbb7d3d4a7700e6e007e679a8706d8be0 but not with that patch reverted.

Because there is a lot of flakiness in the tree, I am going to revrert 7521deccbb7d3d4a7700e6e007e679a8706d8be0 based on this.

Removing sheriff label as it looks like the revert worked.

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

commit 2c76a0fac8022f693c0ee86a18676734b79e8512
Author: Arthur Sonzogni <arthursonzogni@chromium.org>
Date: Tue Sep 04 16:49:09 2018

Fix flaky LayoutTest: adopt-iframe-src-attr-after-remove.html

This test was:
  1) using non valid HTML syntax (line 3).
  2) using (for no reason) named access on the window object
     https://html.spec.whatwg.org/#named-access-on-the-window-object
     The iframe with id "iframe" is globally accessible using
     "window.iframe" (or implicitly "iframe"). This is more or less
     deprecated in favor of using document.getElementById("iframe"). It
     causes the test to be flaky (see below for understanding why).

This CL removes 1) and 2).

Why this test is flaky?
---------------------------
Line 37 in DOMContentLoaded handler, adoptAfterLoaded is executed after a 1ms
timeout. If the 'load' event is fired before 1ms, the iframe is removed
and window.iframe is now undefined. Then in adoptAfterLoaded, 'ifr' is
undefined and is dereferenced line 24, the script fails just before calling
testRunner.notifyDone().

Bug: 831155,  861808 
Change-Id: I131dfb3b74c6d3fea1c412b219008a1be544a4f7
Reviewed-on: https://chromium-review.googlesource.com/1202282
Reviewed-by: Camille Lamy <clamy@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#588546}
[modify] https://crrev.com/2c76a0fac8022f693c0ee86a18676734b79e8512/third_party/WebKit/LayoutTests/http/tests/misc/adopt-iframe-src-attr-after-remove.html