I could not see that. I have however 56.x.

Over to malaykeshav@ because scaling.

There is another report https://b.corp.google.com/issues/31737761.

I haven't seen a report on other boards, and couldn't repro on peach-pi (on both this and ToT), so this is probably Elm specific. If this is working on 56, then it might have been fixed.

Still broken on latest elm beta - 55.0.2883.29 / 8872.27.0.

This's another report https://feedback.corp.google.com/#/Report/15693233293

Still happened on elm beta - 55.0.2883.35 / 8872.35.0 from the above user feedback 

marcheu@, I think this is Elm specific. Can someone in your team look into this from driver/kernel perspective?

@#7 - no, this is not elm specific.
I can repro on both peach_pi @ 8791.0 / 55.0.2857.0
Also, it is not fixed, I can repro on elm 56.0.2915.0 / 8975.0.0

Thanks, I confirmed that I could repro on other as well as on linux desktop.

 Issue 674214  has been merged into this issue.

#9 - I tried reproducing the error on linux with the following command line switches:
./chrome --enable-use-zoom-for-dsf --force-device-scale-factor=1.25 --ash-host-window-bounds="1920x1080"

Was successfully able to produce the error once, but not on any of the subsequent runs. Anything I am missing?

@#11: What version were you testing?

What are your steps to try to repro?

Was able to reproduce the issue. You need another window behind the clipping window to view the transparent strip. The transparent strip is not visible with the wallpaper.

It also only happens if _atleast_ one of the windows is maximized.

Debugging the issue let to this problem existing on every scale factor > 1 and not just 2.0.

There occurs a dead-strip on the screen that stretches end-to-end horizontally and has a height of approximately the shelf task bar.

The problem has the following quirks and points that would help in debugging:
 - Happens only if at-least one of the window is maximized.
 - The Y-origin for the start of dead-strip depends on the height of 
   the window that is being incorrectly clipped.
 - Playing youtube video in a window does not effect the clipping. It is 
   still clipped incorrectly.
 - Only the active window is clipped.
 - If dev tools is active, only the content is clipped, not the dev tools.

Deleted: Effect on Video Playback.mp4 550 KB

	Effect on Video Playback.mp4 550 KB View Download

Deleted: Layer and Quad bounds enabled.mp4 445 KB

	Layer and Quad bounds enabled.mp4 445 KB View Download

Deleted: Only when maximized.mp4 659 KB

	Only when maximized.mp4 659 KB View Download

Deleted: Dev Tools is not effected.png 329 KB

	Dev Tools is not effected.png 329 KB View Download

The underlying cause for this bug is due to occlusion.

The call happens here:
https://cs.chromium.org/chromium/src/cc/layers/surface_layer_impl.cc?rcl=2686c2ee9e80f445659632d5d507694c0e0f3fc4&l=81

Occlusion::GetUnoccludedContentRect(...) expects the size of the surface in DIP since it applies the layer root DrawTransform() to it. https://cs.chromium.org/chromium/src/cc/layers/layer_impl.cc?l=987

The draw transform moves the bounds to the actual screen location and also scales it. But in the case of surface_layer_impl the bounds we send are already scaled.
This causes the rect to be scaled twice and get logically occluded by the shelf bar at the bottom. (This is also confirmed from the fact that the bug only occurs when atleast one of the window is maximized since that changes the taskbar to opaque from transparent. The fact that the Y-Origin on the dead strip is dependent on the height of the window also confirms this)

@jaydasika, @weiliangc and @ajuma can better explain the working behind this.

Modifying the title to match the bug.

Device: All CrOS devices with DSF > 1.0

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

commit 9c7c49cb95b000cdaef78de90eb6a3cd46c663f9
Author: malaykeshav <malaykeshav@chromium.org>
Date: Fri Feb 10 22:14:21 2017

Changes the bounds being sent for occlusion from physical pixels to DIP

Occlusion::GetUnoccludedContentRect() applies a draw transform to the
bounds being sent. This draw transform already has the scaling applied
to it which causes the physical pixel bounds to be scaled again
leading to an incorrect visible rect result.

Also adds unittest to check for this scenario in the future.

BUG= 660744 
COMPONENT=CC, Layer, Surface Layer Impl
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

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

[modify] https://crrev.com/9c7c49cb95b000cdaef78de90eb6a3cd46c663f9/cc/layers/surface_layer_impl.cc
[modify] https://crrev.com/9c7c49cb95b000cdaef78de90eb6a3cd46c663f9/cc/layers/surface_layer_impl_unittest.cc
[modify] https://crrev.com/9c7c49cb95b000cdaef78de90eb6a3cd46c663f9/cc/test/layer_test_common.cc

What releases have this fix?
Is it in M58?
Can we please merge to M57 before it goes stable?

This bug requires manual review: We are only 4 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

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

This patch first appears in: 58.0.3009.0, which for ChromeOS means any version newer than 9282.0.0.