Add enableReferrers and enableHyperlinkAuditing to contentSettings.misc API.

chrome/browser/profiles/profile_io_data.h

 // 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.
 
 #ifndef CHROME_BROWSER_PROFILES_PROFILE_IO_DATA_H_
 #define CHROME_BROWSER_PROFILES_PROFILE_IO_DATA_H_
 #pragma once
 
 #include "base/basictypes.h"
 #include "base/file_path.h"
@@ skipping 16 matching lines @@
 class HostZoomMap;
 class IOThread;
 namespace net {
 class DnsCertProvenanceChecker;
 class NetLog;
 class ProxyConfigService;
 class ProxyService;
 class SSLConfigService;
 class TransportSecurityState;
 }  // namespace net
+template<class T> class PrefMember;
 namespace prerender {
 class PrerenderManager;
 };  // namespace prerender
 class ProtocolHandlerRegistry;
 namespace webkit_database {
 class DatabaseTracker;
 }  // webkit_database
 
+typedef PrefMember<bool> BooleanPrefMember;
+
 // Conceptually speaking, the ProfileIOData represents data that lives on the IO
 // thread that is owned by a Profile, such as, but not limited to, network
 // objects like CookieMonster, HttpTransactionFactory, etc. The Profile
 // implementation will maintain a reference to the ProfileIOData. The
 // ProfileIOData will originally own a reference to the ChromeURLRequestContexts
 // that reference its members. When an accessor for a ChromeURLRequestContext is
 // invoked, then ProfileIOData will release its reference to the
 // ChromeURLRequestContext and the ChromeURLRequestContext will acquire a
 // reference to the ProfileIOData, so they exchange ownership. This is done
 // because it's possible for a context's accessor never to be invoked, so this
@@ skipping 54 matching lines @@
     scoped_refptr<prerender::PrerenderManager> prerender_manager;
     scoped_refptr<ProtocolHandlerRegistry> protocol_handler_registry;
     // We need to initialize the ProxyConfigService from the UI thread
     // because on linux it relies on initializing things through gconf,
     // and needs to be on the main thread.
     scoped_ptr<net::ProxyConfigService> proxy_config_service;
     // The profile this struct was populated from.
     ProfileId profile_id;
   };
 
-  explicit ProfileIOData(bool is_incognito);
+  explicit ProfileIOData(Profile* profile, bool is_incognito);

[willchan no longer on Chromium, 2011/04/12 16:34:18]

Not explicit anymore.

I have to say, I resisted adding Profile for a long time. The reason is because
ProfileIOData will live on the IO thread. We really don't want to cache the
|profile| pointer, because any use on the IO thread is a bug.

I've been trying to pass the explicit dependency (the initialized
BooleanPrefMember in this case), although I acknowledge that would introduce a
bit of code redundancy. I'm also worried about the ProfileIOData subclasses
caching Profile*. I'm not sure how draconian I should be. I guess I'd be fine
with it if there were comments in the constructors indicating not to cache the
Profile*.

[Bernhard Bauer, 2011/04/12 20:26:05]

Hmm, I could initialize the BooleanPrefMember in the ::Handle constructor,
right? There we already have the Profile, and I could even extract a static
helper method similar to InitializeProfileParams() that does the intialization.

[willchan no longer on Chromium, 2011/04/12 22:43:07]

Yes, I would be fine with that. That's what I referred to in causing code
redundancy, since It'd have to be done for both ProfileImplIOData::Handle and
OffTheRecordProfileIOData::Handle.

[Bernhard Bauer, 2011/04/13 11:17:20]

OK, done (in ChromeNetworkDelegate now, so it can be used by IOThread as well).

   virtual ~ProfileIOData();
 
   // Static helper functions to assist in common operations executed by
   // subtypes.
 
   static void InitializeProfileParams(Profile* profile, ProfileParams* params);
   static void ApplyProfileParamsToContext(const ProfileParams& profile_params,
                                           ChromeURLRequestContext* context);
 
   // Lazy initializes the ProfileIOData object the first time a request context
   // is requested. The lazy logic is implemented here. The actual initialization
   // is done in LazyInitializeInternal(), implemented by subtypes. Static helper
   // functions have been provided to assist in common operations.
   void LazyInitialize() const;
 
+ protected:

[willchan no longer on Chromium, 2011/04/12 16:34:18]

Look at line 73, there's already a protected section. Actually, everything below
should be private. Other than the new member functions you've added.

[Bernhard Bauer, 2011/04/13 11:17:20]

Oops, done.

   // --------------------------------------------
   // Virtual interface for subtypes to implement:
   // --------------------------------------------
 
   // Does the actual initialization of the ProfileIOData subtype. Subtypes
   // should use the static helper functions above to implement this.
   virtual void LazyInitializeInternal() const = 0;
 
   // Does an on-demand initialization of a RequestContext for the given
   // isolated app.
   virtual scoped_refptr<RequestContext> InitializeAppRequestContext(
       scoped_refptr<ChromeURLRequestContext> main_context,
       const std::string& app_id) const = 0;
 
   // These functions are used to transfer ownership of the lazily initialized
   // context from ProfileIOData to the URLRequestContextGetter.
   virtual scoped_refptr<ChromeURLRequestContext>
       AcquireMainRequestContext() const = 0;
   virtual scoped_refptr<ChromeURLRequestContext>
       AcquireMediaRequestContext() const = 0;
   virtual scoped_refptr<ChromeURLRequestContext>
       AcquireExtensionsRequestContext() const = 0;
   virtual scoped_refptr<ChromeURLRequestContext>
       AcquireIsolatedAppRequestContext(
           scoped_refptr<ChromeURLRequestContext> main_context,
           const std::string& app_id) const = 0;
 
+  // Called when the profile is destroyed.
+  void Shutdown();

[willchan no longer on Chromium, 2011/04/12 16:34:18]

ShutdownOnUI()

[Bernhard Bauer, 2011/04/13 11:17:20]

Done.

+
+  BooleanPrefMember* enable_referrers() const {
+    return enable_referrers_.get();
+  }
+
+ private:
+  scoped_ptr<BooleanPrefMember> enable_referrers_;

[willchan no longer on Chromium, 2011/04/12 16:34:18]

Why use a pointer? Can't we just directly embed the BooleanPrefMember and
construct it in the initializer list?

[Bernhard Bauer, 2011/04/13 11:17:20]

Very nice! Done.

   mutable bool initialized_;
 
   DISALLOW_COPY_AND_ASSIGN(ProfileIOData);
 };
 
 #endif  // CHROME_BROWSER_PROFILES_PROFILE_IO_DATA_H_