Listen to didReceiveResponse() to get the response in WebViewPlugin.

components/plugins/renderer/webview_plugin.cc

Index: components/plugins/renderer/webview_plugin.cc
diff --git a/components/plugins/renderer/webview_plugin.cc b/components/plugins/renderer/webview_plugin.cc
index 81a26f43427684f980d4cb681c1315919cbe63f9..4bdc330a422ec4fd6ea1dc7e142f48ec49d7ae6b 100644
--- a/components/plugins/renderer/webview_plugin.cc
+++ b/components/plugins/renderer/webview_plugin.cc
@@ -95,9 +95,8 @@ WebViewPlugin::~WebViewPlugin() {
 }
 
 void WebViewPlugin::ReplayReceivedData(WebPlugin* plugin) {
-  const WebURLResponse& response = web_frame_->dataSource()->response();
-  if (!response.isNull()) {
-    plugin->didReceiveResponse(response);
+  if (!response_.isNull()) {
+    plugin->didReceiveResponse(response_);
     size_t total_bytes = 0;
     for (std::list<std::string>::iterator it = data_.begin(); it != data_.end();
          ++it) {
@@ -124,6 +123,11 @@ void WebViewPlugin::ReplayReceivedData(WebPlugin* plugin) {
   }
 }
 
+void WebViewPlugin::didReceiveResponse(const WebURLResponse& response) {
+  if (!response_.isNull())

[tommycli, 2016/09/15 23:53:35]

This line used to be DCHECK(response_.isNull());

Did you mean "response" the function argument instead of the member var?

[tommycli, 2016/09/16 00:01:38]

Restoring the old DCHECK crashes, so I'm guessing something has changed about
how these responses work.

The patch as-is works, but I'm not sure, since it would seem that
response_.isNull() would be initially true, and the member variable would never
be populated.

[Bernhard Bauer, 2016/09/16 10:28:01]

Huh, that's strange. Where would the non-null value come from? Is this being
called more than once now?

[Nate Chapin, 2016/09/16 17:17:54]

Yeah this patchset only works accidentally: I inverted the if() statement, and
therefore response_ will always be null. To understand why this fixes the issue,
let's start at the beginning!

While I was working on
https://crrev.com/8489f1bf78c2c6f296e0df6c529751d29e8a0188, I ran into a
problem: I had changed WebFrameClient::didReceiveResponse() to just have a
single const WebURLResponse& parameter. This meant that WebViewPlugin had a
diamond inheritance problem, as it implements both WebFrameClient and WebPlugin,
and both of these functions now had a didReceiveResponse() callback with
identical parameters.

I believe the key is that the WebPlugin::didReceiveResponse() callback was
*never* getting called for a WebViewPlugin. WebViewPlugin initializes its frame
with a data: url, so a PluginDocument isn't created in blink, and without a
PluginDocument, there are no WebPlugin::didReceiveResponse() callbacks. But with
the diamond inheritance, it was now picking up the response from the
WebFrameClient::didReceiveResponse() callbacks, none of which are actually the
plugin data. I settled on "fixing" this in
https://crrev.com/8489f1bf78c2c6f296e0df6c529751d29e8a0188 by getting an
irrelevant WebURLResponse a different way, not realizing that all of
WebViewPlugin's response handling is dead code.

So I goofed in that patch, and it appears this patchset fixes the issue by
introducing different, subtly dead code. I believe the right solution is to
simply remove any logic that handles a WebURLResponse. Updated patch to reflect
that. There is probably more to remove, but I'll stick to that in this patch.

+    response_ = response;
+}
+
 void WebViewPlugin::RestoreTitleText() {
   if (container_)
     container_->element().setAttribute("title", old_title_);