Narrow Bisect info:
https://chromium.googlesource.com/chromium/src/+log/7e7d3daff9117163ca29f1614a9e45ee1cb47b23..c80c8d6b64756dbd6b3a34cbf2f7f5e6473eed0c?pretty=fuller&n=10000

Suspecting : r390131 from Narrow Bisect

Note : Above issue is not seen on Linux (ubuntu 14.04 LTS) OS.

Adding RB label as this is a recent regression.

@samli, I think this may be an animations issue.  Whenever the orientation option is selected or the reset button is clicked, it boils down to a _setBoxOrientation() call in SensorsView.js

If the view adds a CSS transition class and updates the value of 'webkitTransform', there shouldn't be unwanted traces.  Could you please take a look or offer advice, Sam?

Unable to reproduce on Mac 52.0.2720.0.

Unable to reproduce the issue on Windows 7 using chrome latest canary M52-52.0.2723.0. Observed no black traces while flipping the Device model.

yfulgaonkar@ - Could you please recheck this issue on latest chrome canary and kindly update this bug.

Thanks!

Update from my end: Able to repro this bug on Windows 7 using 52.0.2720.0.  Unable to reproduce on Mac or Linux 52.0.2723.0.

I'm not sure why this occurs, since it should be declaratively setting the 3D transforms.  Maybe someone on [blink-paint] can offer insight?

Also, there is an upcoming CL currently in review that will update the 3D phone with new images, which may impact this issue.  https://codereview.chromium.org/1923843003/

I can repro this on Win7, but the behavior is inconsistent. It seems like we sometimes update the animation but fail to invalidate correctly for that frame. Most of the time we get it right, which suggest some race condition. Also, the artifact tends to get painted over quite quickly.

This should be a compositor animation if a 3D transform is involved (how do I run DevTools on DevTools?). So adding Compositor component, marking it as Untriaged, and CCing some of the usual suspects. I personally have no idea how invalidation works in this case.

luoe@ can confirm. But yes, just some transforms.
You can run Devtools on Devtools by popping out the Devtools window and using Ctrl+Shift+I shortcut again.

(https://chromium.googlesource.com/chromium/src/+/c80c8d6b64756dbd6b3a34cbf2f7f5e6473eed0c/third_party/WebKit/Source/devtools/front_end/emulation/sensors.css)

I can reproduce on Linux.

@luoe: are you simply setting the transform: matrix(...) property on the
element with class accelerometer-box? I tried that directly by inspecting the
inspector and setting the property directly; it had no artifacts (not sure why,
but it didn't).

Can you reproduce this on a standalone webpage?

This could be a damage tracking bug in cc, particularly if it only happens when using a composited animation and not when setting the property directly.

I had a similar thought. It also doesn't repro if you turn on "paint flashing"
or the frame rate widget in cc. What's an easy way to hack the code to test this
theory?

Making LayerImpl::LayerPropertyChanged always return true should do it (assuming the bug is failing to note that a layer property changed, rather than incorrectly computing the union of the old position and new one).

@chrishtr: I am just setting the style.webkitTransform to a new matrix on an element with a transition rule.

Let me see if I can make a standalone webpage for repro and forward it to you.

ps. use unprefixed transform.

That did the trick. Returning true from LayerImpl::LayerPropertyChanged causes the bug to no longer reproduce. Ali, sending to you for next steps.

With response to comment #5

Rechecked this issue on Windows 7 using latest canary M52-52.0.2723.0 and still able to reproduce the issue. Kindly review the attached screen cast.

Deleted: Canary_behavior.mp4 1.0 MB

Canary_behavior.mp4 1.0 MB Download

Still able to repro this issue on Windows 7 & MAC (10.11.4) for Google Chrome Canary Version - 52.0.2724.0 

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

commit 2da9a217f5c47d24bc75a1c7829b104b26bb5aac
Author: ajuma <ajuma@chromium.org>
Date: Wed May 04 22:35:41 2016

cc: Ensure damage in property tree nodes gets propagated to descendants

This propagates damage stored in property tree nodes to descendants, when
damage is copied over from old property trees to new ones. This ensures
that damage is up-to-date even if there are no other reasons to do a
full tree update.

BUG= 607423 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

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

[modify] https://crrev.com/2da9a217f5c47d24bc75a1c7829b104b26bb5aac/cc/trees/layer_tree_host_unittest.cc
[modify] https://crrev.com/2da9a217f5c47d24bc75a1c7829b104b26bb5aac/cc/trees/property_tree.cc

Is this bug in M51 also?

The underlying damage tracking bug in cc is indeed a regression in M51 (and can affect regular web content), so we should merge back the fix.

Your change meets the bar and is auto-approved for M51 (branch: 2704)

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

commit ef6b72f211b9882a7264ceec91f3486855f8b84e
Author: Ali Juma <ajuma@chromium.org>
Date: Fri May 06 14:58:40 2016

cc: Ensure damage in property tree nodes gets propagated to descendants

This propagates damage stored in property tree nodes to descendants, when
damage is copied over from old property trees to new ones. This ensures
that damage is up-to-date even if there are no other reasons to do a
full tree update.

BUG= 607423 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/1948163002
Cr-Commit-Position: refs/heads/master@{#391667}
(cherry picked from commit 2da9a217f5c47d24bc75a1c7829b104b26bb5aac)

Review URL: https://codereview.chromium.org/1949253006 .

Cr-Commit-Position: refs/branch-heads/2704@{#418}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/ef6b72f211b9882a7264ceec91f3486855f8b84e/cc/trees/layer_tree_host_unittest.cc
[modify] https://crrev.com/ef6b72f211b9882a7264ceec91f3486855f8b84e/cc/trees/property_tree.cc
[modify] https://crrev.com/ef6b72f211b9882a7264ceec91f3486855f8b84e/cc/trees/property_tree.h

 Issue 607860  has been merged into this issue.

Updating milestone to match the issue that was merged into this one.