Indicate in the tab UI if appcache creation was blocked by privacy settings.

chrome/renderer/renderer_webapplicationcachehost_impl.cc

+// Copyright (c) 2010 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "chrome/renderer/renderer_webapplicationcachehost_impl.h"
+
+#include "chrome/common/content_settings_types.h"
+#include "chrome/renderer/render_thread.h"
+#include "chrome/renderer/render_view.h"
+
+using appcache::AppCacheBackend;
+using WebKit::WebApplicationCacheHostClient;
+
+RendererWebApplicationCacheHostImpl::RendererWebApplicationCacheHostImpl(
+    RenderView* render_view,
+    WebApplicationCacheHostClient* client,
+    AppCacheBackend* backend)
+    : WebApplicationCacheHostImpl(client, backend),
+      content_blocked_(false),
+      render_view_(render_view) {
+}
+
+RendererWebApplicationCacheHostImpl::~RendererWebApplicationCacheHostImpl() {
+}
+
+void RendererWebApplicationCacheHostImpl::OnContentBlocked() {
+  if (!content_blocked_) {
+    RenderThread::current()->Send(new ViewHostMsg_ContentBlocked(
+        render_view_->routing_id(), CONTENT_SETTINGS_TYPE_COOKIES));

[michaeln, 2010/04/08 18:17:42]

Here's where the raciness i mentioned earlier comes into play.

I don't think we have any guarantees that the document this appcacheHost is
associated with is still the document that is committed to the frame. If not, we
*could* be erroneously setting the icon.

Also, I don't think we have any guarantee that the RenderView is still
allocated. If not, we *could* crash at this dereference (or pick up odd values
for routing_id).

I think I'd be more comfortable with setting a routing_id_ data member in the
ctor and using that data member here for now. (And not having the render_view_
data member which could be a dangling ptr)

[jochen (gone - plz use gerrit), 2010/04/09 15:44:47]

Done.

+    content_blocked_ = true;
+  }
+}