- screenshots #4 and #6 are with the drawer's z-index removed
 - Repro step 1 should say "note" not "not"

I can't reproduce this on 64.0.3282.140 / Mac retina

What platform can you reproduce on? Also, could you please update to the latest
stable release (64.0.3282.140) and see if it reproduces?

I also cannot reproduce on 64.0.3282.140 / Linux.

Reproduces on Win10 with Chrome Version 65.0.3322.3 (Official Build) canary (64-bit)

Interestingly, when I turned on layer visualization in DevTools I got a crash.

So we do need a Win10 bisect. Putting a 1 week NextAction in case I need to pick this up.

My users that reported it were on:
 - Ubuntu 16.04
 - macOS 10.13.2
 - AntergOS (not sure what version)
 - Windows 10

All using chrome 64.0.3282.119
I also reproduced it in chromium build 533659 on windows 10

Thank you for providing more feedback. Adding requester "schenney@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Just updated to 64.0.3282.140 and it's still happening. 

Able to reproduce the issue on Windows 10, mac 10.12.6 and Ubuntu 14.04 using chrome reported version #64.0.3282.140 and latest canary #66.0.3339.0.

Bisect Information:
=====================
Good build: 64.0.3249.0
Bad Build : 64.0.3250.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/8c7e87211aa02c337795f9260705c47d8a277e5b..eeaf4c2326de12c9b36324a805e46ab933057e54

From the above change log suspecting below change
Change-Id: Ia86c95ca11af2bdafdd6214f9736f4c09592299f
Reviewed-on: https://chromium-review.googlesource.com/735751

sunxd@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.
Note: Adding stable blocker for M-64 as it seems to be a recent regression. please feel free to remove the same if not appropriate.

Thanks...!!

Looking at this. I'm able to reproduce it. I suspect it's a problem associated with occlusion and space transforms.

sunxd@: can you please comment on how severe and user-impacting this issue is? Do you think we can wait until M65 to target this fix? 

abdulsyed@: it's hard to judge imo, when I tested it today it seems the developer has updated with a workaround so that the bug no longer reproduces.

I see that the issue still persists on https://kmymvlp835.codesandbox.io/, but I think we can remove the blocker for now and have the fix in next release.

kaelwd@gmail.com: Hi kaelwd@, can you confirm that there's a workaround being applied?

Great, thanks for confirming. Adding M65 target labels. 

It turns out toggling the drawer adds a translate(300, 0) transform to the mask layer as well as mask layer occlusion. However, when scaling the occlusion in PictureLayerImpl::AppendQuads (https://cs.chromium.org/chromium/src/cc/layers/picture_layer_impl.cc?rcl=f68908b0a84e94689e03f94980fd2c197fc50872&l=280) we apply the quad_to_target_transform to occlusion by overwriting it, so the occlusion now comes with an identity transform, and thus covers most of the clock face.

I think we can combine the quad_to_target_transform and the occlusion's transform here.

Hi enne@, do you think this sounds ok?

sunxd@: yes, there is a workaround in place for the time picker, we just removed paint from the contain rule: https://github.com/vuetifyjs/vuetify/pull/3162/files

Still happens on steppers though, couldn't figure out how to fix that one:
https://next.vuetifyjs.com/en/components/steppers

That sounds pretty reasonable, as this definitely sounds like a bug in occlusion calculations.  Hopefully it should be straightforward to add a unit test for this too.

The NextAction date has arrived: 2018-02-12

M65 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge  into the release branch ASAP. Thank you.

sunxd@,

Friendly ping to get an update on this issue as it marked as M65 stable blocker & M65 stable promotion coming very soon.

Thanks..!

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

commit cf699d7fef4e3f03743cc916209c7ebff5dc7b7a
Author: sunxd <sunxd@chromium.org>
Date: Tue Feb 20 16:36:15 2018

cc: Make solid color mask layer ignore occlusion

Mask layer's occlusion is actually its render surface's occlusion in the
contributed parent surface space.

However, when tiling a solid color mask layer, we used to adopt the logic
from normal picture layers: overwrite the occlusion's transform with the
layer's draw transform. This is problematic because mask layer's draw
transform is to the render surface that owns the mask. In this way, we
can generate the wrong visible quad rect and result in blanks when
rendering.

Since solid color mask layer does not do anything but cannot be fully
avoided in the current code base, we should never apply an occlusion to
it. Any occlusion to the masked content can still take effect by
applying itself to the owning render surface.

Bug:  811143 ,  810820 ,  808372 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: I821492c107c2abadb9b9e6986369c9f6262d0ad4
Reviewed-on: https://chromium-review.googlesource.com/916625
Commit-Queue: Xianda Sun <sunxd@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#537794}
[modify] https://crrev.com/cf699d7fef4e3f03743cc916209c7ebff5dc7b7a/cc/layers/picture_layer_impl.cc
[modify] https://crrev.com/cf699d7fef4e3f03743cc916209c7ebff5dc7b7a/cc/layers/picture_layer_impl_unittest.cc

Requesting merging to M65.

This bug requires manual review: We are only 13 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

This change is not yet baked in canary, pls update the bug with canary result tomorrow. 

As this is regressed in M64 stable and we're very close to M65 stable promotion, can't this wait until M66? If it is imp for M65, how safe is the merge?

Sorry for late comment. I think we should merge it into M65 for:
1) there are three bug reports that points to this bug:  811143 ,  810820  and 	 808372 , it looks like the occlusion bug influences a number of developers out there;
2) The fixing patch is targeted on solid color mask layer only, making the solid color logic identical to non-solid color mask layers. Since non-solid color mask layers have no problem with ignoring occlusions, so should the solid color ones. Also solid color mask layer gets created much less often than normal mask layers, so merging this patch is very likely to influence those three bug cases only.

Thank you sunxd@. Please update the bug with canary result tomorrow. 

M65 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Merge has to happen latest by 4:00 PM PT Monday (02/26/18) in order to make it to last M65 beta release next week. Thank you.

Able to reproduce the issue on Windows 10, mac 10.13.3 and Ubuntu 14.04 using chrome version #64.0.3282.119.

Verified the fix on Mac 10.13.3, Win-10 and Ubuntu 14.04 using latest chrome version #66.0.3352.0 as per comment #0.
Attaching screen cast for reference.
Observed that the entire time picker is displayed as expected.
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!

Deleted: 808372.mp4 1.3 MB

	808372.mp4 1.3 MB View Download

The NextAction date has arrived: 2018-02-22

The time picker on next.vuetifyjs.com already had a workaround applied, the correct link for that is https://kmymvlp835.codesandbox.io/

Confirmed working on there and the steppers page in 66.0.3353.0, thanks guys!

Approving merge to M65 branch 3325 based on comments #28, #31 & #33. Please merge ASAP. Thank you.

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

commit 8b24864f6fb735764abf5e7f2cfd5d269a881b3b
Author: sunxd <sunxd@chromium.org>
Date: Thu Feb 22 17:57:33 2018

cc: Make solid color mask layer ignore occlusion

Mask layer's occlusion is actually its render surface's occlusion in the
contributed parent surface space.

However, when tiling a solid color mask layer, we used to adopt the logic
from normal picture layers: overwrite the occlusion's transform with the
layer's draw transform. This is problematic because mask layer's draw
transform is to the render surface that owns the mask. In this way, we
can generate the wrong visible quad rect and result in blanks when
rendering.

Since solid color mask layer does not do anything but cannot be fully
avoided in the current code base, we should never apply an occlusion to
it. Any occlusion to the masked content can still take effect by
applying itself to the owning render surface.

Bug:  811143 ,  810820 ,  808372 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: I821492c107c2abadb9b9e6986369c9f6262d0ad4
Reviewed-on: https://chromium-review.googlesource.com/916625
Commit-Queue: Xianda Sun <sunxd@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#537794}(cherry picked from commit cf699d7fef4e3f03743cc916209c7ebff5dc7b7a)
Reviewed-on: https://chromium-review.googlesource.com/931903
Reviewed-by: Xianda Sun <sunxd@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#549}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/8b24864f6fb735764abf5e7f2cfd5d269a881b3b/cc/layers/picture_layer_impl.cc
[modify] https://crrev.com/8b24864f6fb735764abf5e7f2cfd5d269a881b3b/cc/layers/picture_layer_impl_unittest.cc

Thanks, I have merged it into M65.