Add enableReferrers and enableHyperlinkAuditing to contentSettings.misc API.

chrome/browser/profiles/profile_io_data.cc

 // Copyright (c) 2011 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/browser/profiles/profile_io_data.h"
 
 #include <string>
 
 #include "base/basictypes.h"
 #include "base/command_line.h"
@@ skipping 111 matching lines @@
 }  // namespace
 
 void ProfileIOData::InitializeProfileParams(Profile* profile,
                                             ProfileParams* params) {
   DCHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
   PrefService* pref_service = profile->GetPrefs();
 
   params->is_incognito = profile->IsOffTheRecord();
   params->clear_local_state_on_exit =
       pref_service->GetBoolean(prefs::kClearSiteDataOnExit);
+  params->enable_referrers.reset(new BooleanPrefMember());
+  params->enable_referrers->Init(prefs::kEnableReferrers,
+                                 profile->GetPrefs(),
+                                 NULL);
+  params->enable_referrers->MoveToThread(BrowserThread::IO);
+  params->enable_referrers->ObserveProfileDestruction(profile);

[willchan no longer on Chromium, 2011/04/05 13:10:41]

Why is this necessary? The associated ProfileIOData / ChromeNetworkDelegate
should die soon after the Profile dies.

[Bernhard Bauer, 2011/04/05 14:49:02]

Sadly, not soon enough. When the PrefMember is destroyed, it has to be
unregistered from observing pref changes, which has to happen a) on the UI
thread, and b) before the PrefService is destroyed (which is not guaranteed to
be after the ChromeNetworkDelegate is destroyed).

[willchan no longer on Chromium, 2011/04/05 15:06:18]

Wait, but this BooleanPrefMember lives in the ChromeNetworkDelegate which lives
on the IO thread. We'd accessing this without locks? Is this safe? It seems a
bit dodgy.

[Bernhard Bauer, 2011/04/05 16:12:59]

We specifically added support for reading prefs without locks on other threads,
by observing pref changes on the UI thread and then updating the cached pref
value on the IO thread. 

[willchan no longer on Chromium, 2011/04/05 17:12:51]

Which PrefService? Sorry, there seem to be a whole bunch and the shutdown
ordering is not obvious to me.
I see, sounds great.

I see that the PROFILE_DESTROYED notification is issued at the start of
~OffTheRecordProfile and ~ProfileImpl. What guarantee is there that this will
hold true? Is this documented somewhere? What happens if a profile releases the
last reference to ProfileIOData before this notification is issued? Currently
the reference is held as a member of a Profile subclass, so it should be
destroyed after the destructor body has run. We don't have any tests enforcing
any ordering, nor any comments. If you're adding an ordering dependency, some
sort of enforcement would be nice.

[Bernhard Bauer, 2011/04/05 18:24:47]

The one returned by |GetPrefs()| (which is the incognito PrefService for an
OffTheRecordProfile and the regular one for a regular ProfileImpl), and it is
destroyed via the ProfileManager in the destructor of BrowserProcessImpl (before
the IO thread is stopped in the same destructor).
I guess none apart from the fact that probably a lot of other stuff will start
failing if we don't send the notification ;-)

I discussed this with Mattias and we agreed that in this case it's probably
easier to watch for a notification than to explicitly |Destroy()| the
PrefMember, as it is pretty hidden in the ChromeNetworkDelegate.
So we should be fine at the moment, right?
Would you be okay with me just adding a comment which states that the
notification should be sent before the other stuff is destroyed? The
use-after-free we'd possibly get when getting it wrong would probably be hard to
reliably test for :-/

[willchan no longer on Chromium, 2011/04/08 19:10:37]

I don't think I like adding implicit notifications like this. First off, it's
dependent on the Profile. It's possible that a good chunk of this code will move
into content/ which doesn't know about Chrome profiles. I prefer explicit
shutdown notifications. I'd rather you add a Shutdown member function to
ProfileImplIOData::Handle(), which calls ProfileImplIOData::Shutdown(), which
notifies objects as necessary. This way, if we need to forward such shutdown
notifications to the content/ code, we won't have to hook the Profile destroyed
notification.

 
   params->appcache_service = profile->GetAppCacheService();
 
   // Set up Accept-Language and Accept-Charset header values
   params->accept_language = net::HttpUtil::GenerateAcceptLanguageHeader(
       pref_service->GetString(prefs::kAcceptLanguages));
   std::string default_charset = pref_service->GetString(prefs::kDefaultCharset);
   params->accept_charset =
       net::HttpUtil::GenerateAcceptCharsetHeader(default_charset);
 
@@ skipping 122 matching lines @@
   context->set_transport_security_state(
       profile_params.transport_security_state);
   context->set_ssl_config_service(profile_params.ssl_config_service);
   context->set_database_tracker(profile_params.database_tracker);
   context->set_appcache_service(profile_params.appcache_service);
   context->set_blob_storage_context(profile_params.blob_storage_context);
   context->set_file_system_context(profile_params.file_system_context);
   context->set_extension_info_map(profile_params.extension_info_map);
   context->set_prerender_manager(profile_params.prerender_manager);
 }