Able to reproduce the issue on windows 7, Ubuntu 14.04 using chrome version 56.0.2924.87 and canary 59.0.3036.0.
This is regression issue broken in M49.Please find the bisect information as below

Narrow Bisect::
Good :: 49.0.2586.0  --    (build revision 363935)
Bad  :: 49.0.2587.0   --   (build revision 364237)

Change Log::
https://chromium.googlesource.com/chromium/src/+log/2237f6025b96bfc54d831833c9c18d083c6d18fb..63d814aa438e153919893ebe86e3c2901d3dd76d

Possible suspect::
https://chromium.googlesource.com/chromium/src/+/9653a8175a97e6f8fa54219c6294ddb71033bfdf

tdresser@ Could you please look into this issue if it is related to your change,else please help us in finding the appropriate owner for this issue.

Thanks,

Downgrading to P2, as if this regressed in M49, and we didn't notice for 7 milestones, it probably isn't P1.

Rob, can you triage this? Someone on threaded-rendering will probably have an easier time of diagnosing what's going on here than I will.

Yi, can you take a look at this? Looks like the scrollbar layer is not affected by the backface visibility but should be.

I also filed  issue 700378  for a clipping issue with the same demo on high dpi.

One more real world example to demonstrate that is not just about scrollbars.
In this case backflip-visibility seems to be completely ignored when will-change is applied.


https://jsfiddle.net/mauron85/bf8zd3v4/

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

commit ab9fb6945b8d58a04bf92eb4dd16f0cd585da359
Author: xidachen <xidachen@chromium.org>
Date: Fri Apr 14 20:00:24 2017

Fix backface-visibility with will-change

In the case where there is a scrollbar with will-change property and its
backface-visibility is set to hidden, the scrollbar will show up when
it is back-flipped. The reason is that we are not setting the backface
visibility for the overflow_controls_host_layer_.

A layout test is added.

BUG= 700013 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

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

[modify] https://crrev.com/ab9fb6945b8d58a04bf92eb4dd16f0cd585da359/third_party/WebKit/LayoutTests/FlagExpectations/enable-slimming-paint-v2
[add] https://crrev.com/ab9fb6945b8d58a04bf92eb4dd16f0cd585da359/third_party/WebKit/LayoutTests/compositing/will-change/will-change-preserve-backface-visibility-expected.html
[add] https://crrev.com/ab9fb6945b8d58a04bf92eb4dd16f0cd585da359/third_party/WebKit/LayoutTests/compositing/will-change/will-change-preserve-backface-visibility.html
[modify] https://crrev.com/ab9fb6945b8d58a04bf92eb4dd16f0cd585da359/third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp

With the CL landed, I created two minimal test cases:
1. https://jsfiddle.net/8fs04e4s/
2. https://jsfiddle.net/wbvwuduz/

The only difference between the two test case is that #1 has a "backface-visibility: hidden;" line in the ".list" style, and #2 doesn't have that.

#1 will hide the scrollbar when hover mouse on top and #2 will show the scrollbar.

Notice that <list> is a sub-div inside <front> div, where <front> div has "backface-visibility: hidden" specified.

So this really boils down to this question: should backface visibility inherit to sub-divs? Can someone more familiar with CSS specification comment on this.

Also, I checked behavior on firefox nightly build, and it is the same as chromium using the above 2 test cases.