Propagate pageScaleFactor to GuestViews

content/renderer/render_frame_impl.cc

Index: content/renderer/render_frame_impl.cc
diff --git a/content/renderer/render_frame_impl.cc b/content/renderer/render_frame_impl.cc
index a7492bb2d872e90fc04cf365e47c633da40d5260..7270d8f96938d64c3f6e49cc93ba610324cc136a 100644
--- a/content/renderer/render_frame_impl.cc
+++ b/content/renderer/render_frame_impl.cc
@@ -2833,6 +2833,10 @@ void RenderFrameImpl::didCommitProvisionalLoad(
     internal_data->set_must_reset_scroll_and_scale_state(false);
   }
 
+  // The browser wants to be notified of the page scale factor upon navigation.
+  if (is_main_frame_)

[Charlie Reis, 2015/10/30 22:29:08]

In patch 6, you had this operation inside a
details.is_navigation_to_different_page() block, which meant that it wouldn't
happen for in-page navigations.  I thought that was intentional, because page
scale wouldn't change for in-page navigations.

Here you're not checking for that.  Should you check for something like
!navigation_state->WasWithinSamePage(), such as the block on line 2812?  Is that
the correct check?  (I'm not sure when page scale can change on a navigation.)

I was also trying to suggest the
internal_data->must_reset_scroll_and_scale_state() block, just based on the
name.  Is there some proper way to know whether the page scale has changed, and
thus we need to send an update?

In that sense, I'm also wondering why Blink isn't calling
pageScaleFactorChanged() directly after a navigation, if it does change in some
cases.  If it did, we might not need to add code in content for this.

+    render_view_->pageScaleFactorChanged();
+
   bool is_new_navigation = commit_type == blink::WebStandardCommit;
   if (is_new_navigation) {
     // We bump our Page ID to correspond with the new session history entry.