New issue
Advanced search Search tips

Issue 614215 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Aug 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

OOPIF draws at incorrect size on second monitor

Project Member Reported by creis@chromium.org, May 24 2016

Issue description

Version: 52.0.2727.0
OS: ChromeOS

What steps will reproduce the problem?
(1) Start Chrome in --isolate-extensions (or --site-per-process).
(2) Attach a second monitor.
(3) Create a tab on the second display to a page with an OOPIF.
(e.g., chrome-extension://ldngjhkgckijklngngononnejmadojce/options.html in --isolate-extensions, after installing https://chrome.google.com/webstore/detail/beautify-fb/ldngjhkgckijklngngononnejmadojce)

What is the expected output?  What do you see instead?

The OOPIF paints too small within its iframe.

I'm seeing this on a Pixel (high DPI device), and I think we've seen it on Alex's MacBook Pro as well in the past (also high DPI).  I suspect we're using the device's scale factor for OOPIFs on the secondary display, similar to  issue 596092  (which turned out to be  issue 528407 ).  James or Lucas, can you take a look?

Not sure if this affects other aspects of zoom.
 
Screenshot 2016-05-23 at 4.46.00 PM - Display 2.png
520 KB View Download
Cc: osh...@chromium.org
creis@ - I'm assuming this only repros on a Pixel (or other CrOS device with scale factor != 1), is that right?

+ oshima@ since this is related to device scale factor.

I'm guessing that somewhere in my OOPIF-Zoom work I've missed adding in a device_scale_factor when providing zoom levels to subframes.

oshima@ - is there any way to reproduce something like this on the Linux desktop? I.e. have a different device scale factor in a newly opened window (I only ask as it will be faster to debug this if I don't have to set up a test-mode Pixel).

Comment 2 by creis@chromium.org, May 25 2016

I think it would repro on a Mac with a Retina display as well, if that helps.  (I don't have a laptop with non-high-DPI display anymore to test on, but I doubt they would be affected given the symptoms.)

Comment 3 by lfg@chromium.org, May 25 2016

I've known about another similar issue as well -- when you move the window from a screen to another screen with a different DSF, we don't propagate the DSF change.

I think this should be relatively simple to fix. This information is in RenderWidgetHostViewAura (see GetScreenInfo) and needs to be propagated to the child frames.

Comment 4 by creis@chromium.org, Jun 6 2016

Just checking in.  oshima@ or wjmaclean@, can you find a way to repro?  A MacBook Pro might be a good option.
sorry I missed the message #1. Following flag creates two displays when running chrome for chromeos on linux desktop.

--ash-host-window-bounds=0+0-1000x600,0+600-1000x800*2

one at 0,0 with dsf=1 and two at 0,600 with dsf=2




Comment 6 by creis@chromium.org, Jun 8 2016

Labels: M-53
Status: Started (was: Assigned)
Thanks for the info in #5 ... it will make debugging this *much* easier :-)
Project Member

Comment 8 by sheriffbot@chromium.org, Jul 9 2016

Labels: -M-53 M-54 MovedFrom-53
Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 9 by creis@chromium.org, Aug 1 2016

Just checking in-- do you think we can get this for M54?
Yes, just working on a test for it ...
Project Member

Comment 11 by bugdroid1@chromium.org, Aug 11 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80

commit 8a795f3a48e4e77fabd7b0bb35ee43dac910bb80
Author: wjmaclean <wjmaclean@chromium.org>
Date: Thu Aug 11 23:49:58 2016

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

Review-Url: https://codereview.chromium.org/2122023002
Cr-Commit-Position: refs/heads/master@{#411451}

[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/devtools/protocol/color_picker.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/devtools/protocol/page_handler.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/frame_host/cross_process_frame_connector.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/frame_host/cross_process_frame_connector.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/frame_host/render_widget_host_view_child_frame.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/frame_host/render_widget_host_view_child_frame.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/frame_host/render_widget_host_view_guest.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/frame_host/render_widget_host_view_guest.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/renderer_host/render_widget_host_delegate.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/renderer_host/render_widget_host_delegate.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/renderer_host/render_widget_host_impl.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/renderer_host/render_widget_host_unittest.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/renderer_host/render_widget_host_view_android.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/renderer_host/render_widget_host_view_android.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/renderer_host/render_widget_host_view_aura.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/renderer_host/render_widget_host_view_aura.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/renderer_host/render_widget_host_view_aura_unittest.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/renderer_host/render_widget_host_view_base.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/renderer_host/render_widget_host_view_mac.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/renderer_host/render_widget_host_view_mac.mm
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/renderer_host/render_widget_host_view_mus.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/renderer_host/render_widget_host_view_mus.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/web_contents/web_contents_impl.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/web_contents/web_contents_impl.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/web_contents/web_contents_view.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/web_contents/web_contents_view_android.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/web_contents/web_contents_view_android.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/web_contents/web_contents_view_aura.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/web_contents/web_contents_view_aura.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/web_contents/web_contents_view_child_frame.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/web_contents/web_contents_view_child_frame.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/web_contents/web_contents_view_guest.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/web_contents/web_contents_view_guest.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/web_contents/web_contents_view_mac.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/web_contents/web_contents_view_mac.mm
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/web_contents/web_contents_view_mus.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/browser/web_contents/web_contents_view_mus.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/common/page_messages.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/renderer/render_view_impl.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/renderer/render_widget.cc
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/renderer/render_widget.h
[modify] https://crrev.com/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80/content/test/test_render_view_host.h

Comment 12 by creis@chromium.org, Aug 12 2016

Hmm, I just built a local Chrome-for-ChromeOS build on Linux at r411765 and this bug doesn't seem fixed by r411451.

I ran with --ash-host-window-bounds=0+0-1000x600,0+600-1000x800*2 and --site-per-process and visited http://csreis.github.io/tests/cross-site-iframe-simple.html in the higher-DPI window.  The iframe didn't paint correctly (as if it thought the frame were larger than it is).

Am I just seeing  issue 621020  at this point?  lfg@, hopefully you can verify as complete the fix for that one?

Comment 13 by creis@chromium.org, Aug 12 2016

Screenshot of comment 12.
614215-screenshot.png
453 KB View Download

Comment 14 by creis@chromium.org, Aug 12 2016

Ah, I think comments 12-13 are indeed about  issue 621020 .  I reverted r411451 locally and the OOPIF was much worse.  (Screenshot attached.)
614215-screenshot2.png
501 KB View Download

Comment 15 by creis@chromium.org, Aug 22 2016

Status: Fixed (was: Started)
I've confirmed that lfg's r412639 (for  issue 621020 ) appears to fix comments 12-13 as well.  I'll mark this fixed.  Thanks!

Sign in to add a comment