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

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

Existing pathways for communicating changes in device scale factor send
the information to RenderWidget via ViewMsg_Resize. However, sub-frames
have a top-level RenderWidget that isn't a RenderView, so the new
device scale factor isn't properly communicated to the RenderViewImpl.

This CL adds a pathway that transmits device scale factor changes as
a PageMsg via WebContentsImpl, ensuring that all RenderViewImpls that
need the information receive it.

BUG=614215
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80
Cr-Commit-Position: refs/heads/master@{#411451}

[wjmaclean, 2016-07-05 16:03:57]

The CQ bit was checked by wjmaclean@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-05 16:04:33]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-05 16:28:27]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-05 16:28:28]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[wjmaclean, 2016-07-05 18:27:33]

The CQ bit was checked by wjmaclean@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-05 18:27:43]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[wjmaclean, 2016-07-05 18:55:06]

Description was changed from

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

Existing pathways for communicating changes in device scale factor send
the information to RenderWidget via ViewMsg_Resize. However, sub-frames
have a top-level RenderWidget that isn't a RenderView, so the new
device scale factor isn't properly communicated to the RenderViewImpl.

This CL adds a pathway that transmits device scale factor changes as
a PageMsg via WebContentsImpl, ensuring that all RenderViewImpls that
need the information receive it.

BUG=614215
==========

to

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

Existing pathways for communicating changes in device scale factor send
the information to RenderWidget via ViewMsg_Resize. However, sub-frames
have a top-level RenderWidget that isn't a RenderView, so the new
device scale factor isn't properly communicated to the RenderViewImpl.

This CL adds a pathway that transmits device scale factor changes as
a PageMsg via WebContentsImpl, ensuring that all RenderViewImpls that
need the information receive it.

BUG=614215
==========

[wjmaclean, 2016-07-05 18:55:06]

wjmaclean@chromium.org changed reviewers:
+ oshima@chromium.org

[wjmaclean, 2016-07-05 18:56:39]

oshima@ - This is still a WIP, but can you give it a quick once over for sanity?
In particular, I'd be interested in your thoughts on my to-do comments regarding
physical_backing_size in the ResizeParams.

[commit-bot: I haz the power, 2016-07-05 19:23:45]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-05 19:23:46]

Dry run: This issue passed the CQ dry run.

[wjmaclean, 2016-07-07 16:42:25]

wjmaclean@chromium.org changed reviewers:
+ creis@chromium.org

[wjmaclean, 2016-07-07 16:43:55]

oshima@ - can you look this over for basic sanity? I have embedded a couple of
questions in comments. Also, are there existing tests for changing
device_scale_factor that I can look at in order to come up with idea for testing
this?

[oshima, 2016-07-07 20:47:24]

sorry about the delay. looking now.

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

For tests, there are only a couple of that tests dsf but may not be useful for
your case. (file:content/browser/renderer_host/.*test.cc eviceScaleFactor)

I'm also not familiar with how oopif works. maybe we should have a quick offline
chat?

https://codereview.chromium.org/2122023002/diff/20001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/2122023002/diff/20001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_impl.cc:593: //
ScaleToCeiledSize(new_size, device_scale_factor) ??
Ideally we should just send the backing size (or pixel size) + scale factor
(then compute dip size where necessary) because that's what renderer will use to
render the content.

https://codereview.chromium.org/2122023002/diff/20001/content/browser/web_con...
File content/browser/web_contents/web_contents_impl.cc (right):

https://codereview.chromium.org/2122023002/diff/20001/content/browser/web_con...
content/browser/web_contents/web_contents_impl.cc:975: new
PageMsg_SetDeviceScaleFactor(MSG_ROUTING_NONE, device_scale_factor));
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.

https://codereview.chromium.org/2122023002/diff/20001/content/browser/web_con...
content/browser/web_contents/web_contents_impl.cc:990: return
RenderWidgetHostDelegate::DefaultDeviceScaleFactor();
web content's view should also knows about the current scale factor.

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

See comments/questions below.

https://codereview.chromium.org/2122023002/diff/20001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/2122023002/diff/20001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_impl.cc:593: //
ScaleToCeiledSize(new_size, device_scale_factor) ??
On 2016/07/07 22:45:43, oshima wrote:
> Ideally we should just send the backing size (or pixel size) + scale factor
> (then compute dip size where necessary) because that's what renderer will use
to
> render the content.

Ok ... so we would send the dsf and physical_backing_size explicitly ... does
dip size change in this case, i.e. if just dsf is changing?

https://codereview.chromium.org/2122023002/diff/20001/content/browser/web_con...
File content/browser/web_contents/web_contents_impl.cc (right):

https://codereview.chromium.org/2122023002/diff/20001/content/browser/web_con...
content/browser/web_contents/web_contents_impl.cc:975: new
PageMsg_SetDeviceScaleFactor(MSG_ROUTING_NONE, device_scale_factor));
On 2016/07/07 22:45:43, oshima wrote:
> 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.

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 ...

https://codereview.chromium.org/2122023002/diff/20001/content/browser/web_con...
content/browser/web_contents/web_contents_impl.cc:990: return
RenderWidgetHostDelegate::DefaultDeviceScaleFactor();
On 2016/07/07 22:45:43, oshima wrote:
> web content's view should also knows about the current scale factor.

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

[oshima, 2016-07-12 14:14:41]

https://codereview.chromium.org/2122023002/diff/40001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/2122023002/diff/40001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_impl.cc:1225:
result->deviceScaleFactor = delegate_->DefaultDeviceScaleFactor();
Since delegate_ is always available (except for shutdown), it probably makes
sense to implement

delegate_->GetScreenInfo(WebScreenInfo*)

instead, and let WebContentsImpl ask WebContentsView to get the WebScreenInfo,
instead of RWHV. You should be able to move the GetScerenInfo impl from RWHV
impl to WebContentsView impl.

https://codereview.chromium.org/2122023002/diff/40001/content/renderer/render...
File content/renderer/render_widget.cc (right):

https://codereview.chromium.org/2122023002/diff/40001/content/renderer/render...
content/renderer/render_widget.cc:1575: physical_backing_size_ =
gfx::ScaleToCeiledSize(size_, device_scale_factor_);
physical_backing_size_ is resized in OnResize.

I think it's better to fold this method into OnResize, and then rename this to
OnSetDeviceScaleFactor. Update the size after OnDeviceScaleFactorChanged to keep
the order in sync with OnResize.

[wjmaclean, 2016-07-28 20:20:25]

Description was changed from

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

Existing pathways for communicating changes in device scale factor send
the information to RenderWidget via ViewMsg_Resize. However, sub-frames
have a top-level RenderWidget that isn't a RenderView, so the new
device scale factor isn't properly communicated to the RenderViewImpl.

This CL adds a pathway that transmits device scale factor changes as
a PageMsg via WebContentsImpl, ensuring that all RenderViewImpls that
need the information receive it.

BUG=614215
==========

to

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

Existing pathways for communicating changes in device scale factor send
the information to RenderWidget via ViewMsg_Resize. However, sub-frames
have a top-level RenderWidget that isn't a RenderView, so the new
device scale factor isn't properly communicated to the RenderViewImpl.

This CL adds a pathway that transmits device scale factor changes as
a PageMsg via WebContentsImpl, ensuring that all RenderViewImpls that
need the information receive it.

BUG=614215
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

[wjmaclean, 2016-07-28 20:21:39]

The CQ bit was checked by wjmaclean@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-28 20:22:06]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-28 20:37:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-28 20:37:09]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[wjmaclean, 2016-07-29 13:19:35]

Patchset #5 (id:80001) has been deleted

[wjmaclean, 2016-07-29 13:50:05]

The CQ bit was checked by wjmaclean@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-29 13:50:25]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-29 14:11:07]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-29 14:11:09]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[wjmaclean, 2016-07-29 14:42:06]

Patchset #5 (id:100001) has been deleted

[wjmaclean, 2016-07-29 14:42:26]

The CQ bit was checked by wjmaclean@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-29 14:42:42]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-29 15:28:27]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-29 15:28:28]

Dry run: This issue passed the CQ dry run.

[wjmaclean, 2016-07-29 17:12:37]

https://codereview.chromium.org/2122023002/diff/40001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/2122023002/diff/40001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_impl.cc:1225:
result->deviceScaleFactor = delegate_->DefaultDeviceScaleFactor();
On 2016/07/12 14:14:41, oshima wrote:
> Since delegate_ is always available (except for shutdown), it probably makes
> sense to implement
> 
> delegate_->GetScreenInfo(WebScreenInfo*)
> 
> instead, and let WebContentsImpl ask WebContentsView to get the WebScreenInfo,
> instead of RWHV. You should be able to move the GetScerenInfo impl from RWHV
> impl to WebContentsView impl.

Done (I think).

I've moved the GetScreenInfo() machinery into the WebContentsView* hierarchy ...
it involved moving a lot of stuff around, so please let me know if what I've
done matches what you had in mind.

https://codereview.chromium.org/2122023002/diff/40001/content/renderer/render...
File content/renderer/render_widget.cc (right):

https://codereview.chromium.org/2122023002/diff/40001/content/renderer/render...
content/renderer/render_widget.cc:1575: physical_backing_size_ =
gfx::ScaleToCeiledSize(size_, device_scale_factor_);
On 2016/07/12 14:14:41, oshima wrote:
> physical_backing_size_ is resized in OnResize.
> 
> I think it's better to fold this method into OnResize, and then rename this to
> OnSetDeviceScaleFactor. Update the size after OnDeviceScaleFactorChanged to
keep
> the order in sync with OnResize.

I'm not sure I follow. By "fold" do you mean to put the code above this comment
into OnResize()?

When you say "update the size" do you mean the value of physical_backing _size_?
We cannot call OnResize() from here since we only have a new device scale
factor, and not an entire set of resize params. Finally, if we rename this to
OnSetDeviceScaleFactor, is that what the other current callers of this function
should call? If so, the logic they were expecting won't be here anymore.

[oshima, 2016-07-29 18:11:46]

thanks, looks good.

https://codereview.chromium.org/2122023002/diff/40001/content/renderer/render...
File content/renderer/render_widget.cc (right):

https://codereview.chromium.org/2122023002/diff/40001/content/renderer/render...
content/renderer/render_widget.cc:1575: physical_backing_size_ =
gfx::ScaleToCeiledSize(size_, device_scale_factor_);
On 2016/07/29 17:12:37, wjmaclean wrote:
> On 2016/07/12 14:14:41, oshima wrote:
> > physical_backing_size_ is resized in OnResize.
> > 
> > I think it's better to fold this method into OnResize, and then rename this
to
> > OnSetDeviceScaleFactor. Update the size after OnDeviceScaleFactorChanged to
> keep
> > the order in sync with OnResize.
> 
> I'm not sure I follow. By "fold" do you mean to put the code above this
comment
> into OnResize()?

Yes.

> 
> When you say "update the size" do you mean the value of physical_backing
_size_?
> We cannot call OnResize() from here since we only have a new device scale
> factor, and not an entire set of resize params.

What I meant is to update & call stuff in the same order as OnResize.

> Finally, if we rename this to
> OnSetDeviceScaleFactor, is that what the other current callers of this
function
> should call? If so, the logic they were expecting won't be here anymore.

It looks to me that OnResize is the only caller. Am I wrong?

https://codereview.chromium.org/2122023002/diff/140001/content/browser/render...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://codereview.chromium.org/2122023002/diff/140001/content/browser/render...
content/browser/renderer_host/render_widget_host_view_aura.cc:1702: //
TODO(wjmaclean): can host_ ever be null?
This is called only when the window is attached to the tree, so technically, it
shouldn't happen.

https://codereview.chromium.org/2122023002/diff/140001/content/browser/web_co...
File content/browser/web_contents/web_contents_impl.cc (right):

https://codereview.chromium.org/2122023002/diff/140001/content/browser/web_co...
content/browser/web_contents/web_contents_impl.cc:980:
GetView()->GetScreenInfo(web_screen_info);
indent

https://codereview.chromium.org/2122023002/diff/140001/content/browser/web_co...
File content/browser/web_contents/web_contents_view_guest.cc (right):

https://codereview.chromium.org/2122023002/diff/140001/content/browser/web_co...
content/browser/web_contents/web_contents_view_guest.cc:69:
guest_->embedder_web_contents()->GetView()->GetScreenInfo(web_screen_info);
nit: indent

[wjmaclean, 2016-07-29 18:38:48]

The CQ bit was checked by wjmaclean@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-29 18:39:21]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[wjmaclean, 2016-07-29 18:40:05]

Ok, I think I see what you're asking w.r.t. to the code in RenderWidget ...
here's a revised version; please let me know if I did what you were expecting.

https://codereview.chromium.org/2122023002/diff/140001/content/browser/render...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://codereview.chromium.org/2122023002/diff/140001/content/browser/render...
content/browser/renderer_host/render_widget_host_view_aura.cc:1702: //
TODO(wjmaclean): can host_ ever be null?
On 2016/07/29 18:11:46, oshima wrote:
> This is called only when the window is attached to the tree, so technically,
it
> shouldn't happen.

Acknowledged.

https://codereview.chromium.org/2122023002/diff/140001/content/browser/web_co...
File content/browser/web_contents/web_contents_impl.cc (right):

https://codereview.chromium.org/2122023002/diff/140001/content/browser/web_co...
content/browser/web_contents/web_contents_impl.cc:980:
GetView()->GetScreenInfo(web_screen_info);
On 2016/07/29 18:11:46, oshima wrote:
> indent

Done.

https://codereview.chromium.org/2122023002/diff/140001/content/browser/web_co...
File content/browser/web_contents/web_contents_view_guest.cc (right):

https://codereview.chromium.org/2122023002/diff/140001/content/browser/web_co...
content/browser/web_contents/web_contents_view_guest.cc:69:
guest_->embedder_web_contents()->GetView()->GetScreenInfo(web_screen_info);
On 2016/07/29 18:11:46, oshima wrote:
> nit: indent

Done.

[commit-bot: I haz the power, 2016-07-29 19:28:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-29 19:28:57]

Dry run: This issue passed the CQ dry run.

[wjmaclean, 2016-08-02 14:15:04]

Description was changed from

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

Existing pathways for communicating changes in device scale factor send
the information to RenderWidget via ViewMsg_Resize. However, sub-frames
have a top-level RenderWidget that isn't a RenderView, so the new
device scale factor isn't properly communicated to the RenderViewImpl.

This CL adds a pathway that transmits device scale factor changes as
a PageMsg via WebContentsImpl, ensuring that all RenderViewImpls that
need the information receive it.

BUG=614215
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

to

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

Existing pathways for communicating changes in device scale factor send
the information to RenderWidget via ViewMsg_Resize. However, sub-frames
have a top-level RenderWidget that isn't a RenderView, so the new
device scale factor isn't properly communicated to the RenderViewImpl.

This CL adds a pathway that transmits device scale factor changes as
a PageMsg via WebContentsImpl, ensuring that all RenderViewImpls that
need the information receive it.

BUG=614215
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

[wjmaclean, 2016-08-02 14:15:04]

wjmaclean@chromium.org changed reviewers:
+ kenrb@chromium.org

[wjmaclean, 2016-08-02 14:16:01]

kenrb@ - Can you please review for SECURITY_OWNERS for page_messages.h ?

[wjmaclean, 2016-08-02 14:43:21]

The CQ bit was checked by wjmaclean@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-02 14:43:32]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-02 15:34:49]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-02 15:34:50]

Dry run: This issue passed the CQ dry run.

[Charlie Reis, 2016-08-08 17:19:16]

On 2016/08/02 14:16:01, wjmaclean wrote:
> kenrb@ - Can you please review for SECURITY_OWNERS for page_messages.h ?

wjmaclean@: What's the status on this one?  I noticed there's some failing tests
in patch 9.  Are you waiting on Ken's review for page_messages.h, or is there
more to do?

(Let me know when you're ready for OWNERS review.)  Thanks!

[wjmaclean, 2016-08-08 17:24:45]

On 2016/08/08 17:19:16, Charlie Reis wrote:
> On 2016/08/02 14:16:01, wjmaclean wrote:
> > kenrb@ - Can you please review for SECURITY_OWNERS for page_messages.h ?
> 
> wjmaclean@: What's the status on this one?  I noticed there's some failing
tests
> in patch 9.  Are you waiting on Ken's review for page_messages.h, or is there
> more to do?
> 
> (Let me know when you're ready for OWNERS review.)  Thanks!

I am waiting for page_message.h, though I suspect that's a simple thing.

No, the bigger delay is sorting out the testing framework with oshima@ (PS9 was
a failed test of a possible framework). I still hope to see that sorted out in
the next day or two ... when it lands the supporting framework will land in a
separate CL. There's is a small addition to render_widget_host_view_mac.mm that
is here ... I'll upload a cleaned version of the current CL later today if you
want to take a look.

[wjmaclean, 2016-08-09 15:15:53]

Here's an updated version of the CL that could be used for an OWNER's review (I
don't think it will change substantially, but not that it depends on oshima@'s
work landing first, and that could still require some minor changes to the
tests).

The CL is landable before oshima@'s CL if we hold back one of the two tests:
DeviceScaleFactorChangePropagatesToAllFrames and the
DisplayMetricsChangedObserver class in site_per_process_browsertest.cc.

kenrb@ - can you please look at page_messages.h ?
creis@ - please feel free to do an OWNER's review on this version.

[kenrb, 2016-08-09 17:01:22]

ipc lgtm

[Charlie Reis, 2016-08-10 00:07:13]

LGTM from an owner's perspective, though I'm not familiar enough with this code
for that to represent an actual review.

oshima@, can you do the actual review?  This is a blocking issue for
--isolate-extensions for M54, so we're hoping to wrap it up.  Thanks!

https://codereview.chromium.org/2122023002/diff/220001/content/browser/web_co...
File content/browser/web_contents/web_contents_impl.h (right):

https://codereview.chromium.org/2122023002/diff/220001/content/browser/web_co...
content/browser/web_contents/web_contents_impl.h:644: 
nit: No extra blank line here.

https://codereview.chromium.org/2122023002/diff/220001/ui/aura/window_tree_ho...
File ui/aura/window_tree_host.h (right):

https://codereview.chromium.org/2122023002/diff/220001/ui/aura/window_tree_ho...
ui/aura/window_tree_host.h:182: // For testing : WJM
WJM?

[oshima, 2016-08-10 07:30:09]

lgtm

I'll send my screen CL to owners once it passed dry run.

[wjmaclean, 2016-08-10 15:54:26]

https://codereview.chromium.org/2122023002/diff/220001/ui/aura/window_tree_ho...
File ui/aura/window_tree_host.h (right):

https://codereview.chromium.org/2122023002/diff/220001/ui/aura/window_tree_ho...
ui/aura/window_tree_host.h:182: // For testing : WJM
On 2016/08/10 00:07:12, Charlie Reis wrote:
> WJM?

Done.

The comment was designed to make sure I didn't leave this in ... thanks for
spotting.

[wjmaclean, 2016-08-11 18:37:01]

Removed second test for now, will run on try bots and (if all is good) try to
land.

https://codereview.chromium.org/2122023002/diff/220001/content/browser/web_co...
File content/browser/web_contents/web_contents_impl.h (right):

https://codereview.chromium.org/2122023002/diff/220001/content/browser/web_co...
content/browser/web_contents/web_contents_impl.h:644: 
On 2016/08/10 00:07:12, Charlie Reis wrote:
> nit: No extra blank line here.

Done.

[wjmaclean, 2016-08-11 18:37:16]

The CQ bit was checked by wjmaclean@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-11 18:38:08]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-11 21:25:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-11 21:25:41]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[wjmaclean, 2016-08-11 22:10:03]

The CQ bit was checked by wjmaclean@chromium.org

[wjmaclean, 2016-08-11 22:10:03]

The patchset sent to the CQ was uploaded after l-g-t-m from kenrb@chromium.org,
creis@chromium.org, oshima@chromium.org
Link to the patchset: https://codereview.chromium.org/2122023002/#ps280001
(title: "Version of patch without second test.")

[commit-bot: I haz the power, 2016-08-11 22:10:48]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-11 23:50:19]

Description was changed from

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

Existing pathways for communicating changes in device scale factor send
the information to RenderWidget via ViewMsg_Resize. However, sub-frames
have a top-level RenderWidget that isn't a RenderView, so the new
device scale factor isn't properly communicated to the RenderViewImpl.

This CL adds a pathway that transmits device scale factor changes as
a PageMsg via WebContentsImpl, ensuring that all RenderViewImpls that
need the information receive it.

BUG=614215
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

to

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

Existing pathways for communicating changes in device scale factor send
the information to RenderWidget via ViewMsg_Resize. However, sub-frames
have a top-level RenderWidget that isn't a RenderView, so the new
device scale factor isn't properly communicated to the RenderViewImpl.

This CL adds a pathway that transmits device scale factor changes as
a PageMsg via WebContentsImpl, ensuring that all RenderViewImpls that
need the information receive it.

BUG=614215
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

[commit-bot: I haz the power, 2016-08-11 23:50:21]

Committed patchset #13 (id:280001)

[commit-bot: I haz the power, 2016-08-11 23:52:28]

Description was changed from

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

Existing pathways for communicating changes in device scale factor send
the information to RenderWidget via ViewMsg_Resize. However, sub-frames
have a top-level RenderWidget that isn't a RenderView, so the new
device scale factor isn't properly communicated to the RenderViewImpl.

This CL adds a pathway that transmits device scale factor changes as
a PageMsg via WebContentsImpl, ensuring that all RenderViewImpls that
need the information receive it.

BUG=614215
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

to

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

Existing pathways for communicating changes in device scale factor send
the information to RenderWidget via ViewMsg_Resize. However, sub-frames
have a top-level RenderWidget that isn't a RenderView, so the new
device scale factor isn't properly communicated to the RenderViewImpl.

This CL adds a pathway that transmits device scale factor changes as
a PageMsg via WebContentsImpl, ensuring that all RenderViewImpls that
need the information receive it.

BUG=614215
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80
Cr-Commit-Position: refs/heads/master@{#411451}
==========

[commit-bot: I haz the power, 2016-08-11 23:52:30]

Patchset 13 (id:??) landed as
https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80
Cr-Commit-Position: refs/heads/master@{#411451}