Migrate HostZoomMap to live in StoragePartition.

content/public/browser/host_zoom_map.h

 // Copyright (c) 2012 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 CONTENT_PUBLIC_BROWSER_HOST_ZOOM_MAP_H_
 #define CONTENT_PUBLIC_BROWSER_HOST_ZOOM_MAP_H_
 
 #include <map>
 #include <string>
 #include <vector>
 
 #include "base/basictypes.h"
 #include "base/callback.h"
 #include "base/callback_list.h"
 #include "content/common/content_export.h"
+#include "url/gurl.h"
 
 namespace content {
 
 class BrowserContext;
 class ResourceContext;
+class SiteInstance;
 class WebContents;
 
 // Maps hostnames to custom zoom levels.  Written on the UI thread and read on
 // any thread.  One instance per browser context. Must be created on the UI
 // thread, and it'll delete itself on the UI thread as well.
 // Zoom can be defined at three levels: default zoom, zoom for host, and zoom
 // for host with specific scheme. Setting any of the levels leaves settings
 // for other settings intact. Getting the zoom level starts at the most
 // specific setting and progresses to the less specific: first the zoom for the
 // host and scheme pair is checked, secondly the zoom for the host only and
@@ skipping 17 matching lines @@
     std::string host;
     std::string scheme;
     double zoom_level;
   };
 
   typedef std::vector<ZoomLevelChange> ZoomLevelVector;
 
   CONTENT_EXPORT static HostZoomMap* GetForBrowserContext(
       BrowserContext* browser_context);
 
+  CONTENT_EXPORT static HostZoomMap* GetForSite(SiteInstance* instance);

[awong, 2014/08/11 22:36:33]

What does this mean semantically? 

Not saying this is bad necessarily, but a SiteInstance is a way to approximate
the grouping of "sites" that need to have scripting relations to one another.
Having a HostZoomMap attached to that without an explanation of why the
SiteInstance is the key seems a little odd...

[wjmaclean, 2014/08/12 16:57:44]

I'm assuming there's a one-to-one relationship between SiteInstances and
StoragePartition, hence a SiteInstance should identify a unique HostZoomMap.
Then the GetForWebContents() accessor is just a convenience.

The accessor via BrowserContext is for the default storage partition, which (at
least at present) is where we expect non-app/WebView pages to end up. UI
elements like wrench menu depend on this. *If* there are tabs displayed in the
main browser window that do not use the default storage partition, then some
issues may arise.

Is my assumption not correct?

Or is this more of a comment-documentation concern?

[Fady Samuel, 2014/08/13 19:45:42]

The signin page currently uses a different storage partition. This just occurred
to me.

+
+  CONTENT_EXPORT static HostZoomMap* GetForWebContents(
+      const WebContents* contents);
+
   // Returns the current zoom level for the specified WebContents. May be
   // temporary or host-specific.
   CONTENT_EXPORT static double GetZoomLevel(const WebContents* web_contents);
 
   // Sets the current zoom level for the specified WebContents. The level may
   // be temporary or host-specific depending on the particular WebContents.
   CONTENT_EXPORT static void SetZoomLevel(const WebContents* web_contents,
                                           double level);
 
   // Copy the zoom levels from the given map. Can only be called on the UI
@@ skipping 71 matching lines @@
   virtual scoped_ptr<Subscription> AddZoomLevelChangedCallback(
       const ZoomLevelChangedCallback& callback) = 0;
 
  protected:
   virtual ~HostZoomMap() {}
 };
 
 }  // namespace content
 
 #endif  // CONTENT_PUBLIC_BROWSER_HOST_ZOOM_MAP_H_