Cross-process frames should be notified of device scale factor changes.

content/browser/web_contents/web_contents_impl.cc

 // 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.
 
 #include "content/browser/web_contents/web_contents_impl.h"
 
 #include <stddef.h>
 
 #include <cmath>
 #include <utility>
@@ skipping 952 matching lines @@
 
   GURL url = HostZoomMap::GetURLFromEntry(entry);
   if (host != net::GetHostOrSpecFromURL(url) ||
       (!scheme.empty() && !url.SchemeIs(scheme))) {
     return;
   }
 
   UpdateZoom(level);
 }
 
+void WebContentsImpl::UpdateDeviceScaleFactor(double device_scale_factor) {
+  SendPageMessage(
+      new PageMsg_SetDeviceScaleFactor(MSG_ROUTING_NONE, device_scale_factor));

[oshima, 2016/07/07 22:45:43]

Doesn't a oop frame receive ScreenInfo? When dsf changes, ScreenInfo changes as
well, so I wonder why we need a separate message just to pas dsf.

[wjmaclean, 2016/07/08 17:38:33]

The OOP frame is informed, but in a sort of round-about manner: the top level
frame gets the resize message, then it causes an updaterect message to go to
subframes, but the update rect method goes to the subframe's RenderWidget, which
is not the same as its RenderViewImpl. We can hack a connection between the two,
but sending a PageMessage seemed a better choice, since the message will go
directly to all the affected RenderViewImpls.

Also, if OOP frames are nested several deep, it can take a while for this to
propagate, whereas the page message gets the information to all the frames much
sooner.

As for having a new message, ViewMsg_Resize seems rather heavy weight if it's
just a change in scale factor (though maybe I'm missing something here).
Presumably we could also convert the Resize message into a PageMsg, though I
suspect that would run afoul of pages that may want to use JS to fiddle with
sub-frame sizes. This approach forces us to re-render at the new DSF sooner,
without assuming what will happen with sizes. Sending Resize as a PageMsg also
would be more complicated, as currently it involves a lot of callbacks into
delegates (which are often just the WebContents) ... we would presumably not
want that repetition for multiple frames, and changing the ordering of the
callbacks might have implications ... 

+}
+
+double WebContentsImpl::DefaultDeviceScaleFactor() {
+  // TODO(wjmaclean): is it simpler to just remember the value from the last
+  // call to UpdateDeviceScaleFactor()? It's perhaps not the sort of state we
+  // expect WebContents to be hanging on to.
+  RenderWidgetHostViewBase* rwhv =
+      static_cast<RenderWidgetHostViewBase*>(GetRenderWidgetHostView());
+  if (rwhv) {
+    blink::WebScreenInfo screen_info;
+    rwhv->GetScreenInfo(&screen_info);
+    return screen_info.deviceScaleFactor;
+  }
+
+  return RenderWidgetHostDelegate::DefaultDeviceScaleFactor();

[oshima, 2016/07/07 22:45:43]

web content's view should also knows about the current scale factor.

[wjmaclean, 2016/07/08 17:38:33]

You mean WebContentsView? I looked there but didn't see anything.

+}
+
 WebUI* WebContentsImpl::CreateSubframeWebUI(const GURL& url,
                                             const std::string& frame_name) {
   DCHECK(!frame_name.empty());
   return CreateWebUI(url, frame_name);
 }
 
 WebUI* WebContentsImpl::GetWebUI() const {
   WebUI* commited_web_ui = GetCommittedWebUI();
   return commited_web_ui ? commited_web_ui
                          : GetRenderManager()->GetNavigatingWebUI();
@@ skipping 4178 matching lines @@
   for (RenderViewHost* render_view_host : render_view_host_set)
     render_view_host->OnWebkitPreferencesChanged();
 }
 
 void WebContentsImpl::SetJavaScriptDialogManagerForTesting(
     JavaScriptDialogManager* dialog_manager) {
   dialog_manager_ = dialog_manager;
 }
 
 }  // namespace content