Tested the issue on reported chrome 72.0.3595.0, latest stable 70.0.3538.77, Beta 71.0.3578.20 and on latest chrome 72.0.3596.0 using Mac 10.14.0 and Windows 10 observed inconsistent behavior on all active chrome builds. Hence, considering it as non-regression and marking it as Untriaged. Requesting Dev team to look into it. 

Note: Because of inconsistent behavior unable to provide screencast for reference. Issue not observed on Ubuntu 17.10 and removing Needs-Bisect label to it feel free to ad it back if required. 

Thanks! 

I did a quick test on Chrome 70.0.3538.69 and wasn't able to reproduce this.

I should be able to repro just by going up/down the list and clicking on the snooze icon of a few dozen messages, right?

Hey Rick, do you wanted an animated gif?  Did you try on OS X 10.14.0?

Attaching scrolling issue. I'll get a gif of the menu too.

Deleted: Nov-02-2018 10-17-46.gif 2.0 MB

	Nov-02-2018 10-17-46.gif 2.0 MB View Download

Consistent repro steps for me. See attached gif.

1. Close Google Chrome Canary.
2. Open Google Chrome Canary.
3. Visit http://inbox.google.com
4. Scroll down to the email alerts for this issue.
5. Click Email subject to expand email.
6. Click Snooze Until...

Deleted: Nov-02-2018 10-21-44.gif 771 KB

	Nov-02-2018 10-21-44.gif 771 KB View Download

Reproduces still in 72.0.3601.0

Would you mind looking into this one Morten?

Can't reproduce this with 72.0.3595.2 on Linux.

Build Chromium on my own, and now I can reproduce it.
Chromium	72.0.3603.0 (Developer Build) (64-bit)
Revision	a2b1f7be1d783d8a35c0e94eab367760e6bfa546-refs/heads/master@{#605283}

Bisected to:
https://chromium-review.googlesource.com/c/1066630

I wasn't able to come up with a simplified testcase, but it seems to have something to do with changing will-change on some ancestor from "transform" to the initial value.

The way I reproduced it:
1. Go to http://inbox.google.com
2. Click on the subject of some mail to expand it
3. Click on the snooze button (the clock) of that mail

The menu that then appears looks bad. The content underneath bleeds through. I guess it has to do with paint order. Removing will-change:transform may change from establishing a stacking context to not establishing one.

Reverting the CL makes the problem go away.

Either this needs to be fixed if it's a bug in Chrome, or we need Inbox
fixed. Need to decide if the Inbox issue is going to be common on other websites
if the latter course is chosen.

It may be worth testing Firefox/Edge here, *if* we can assume they get the same behavior in Inbox (e.g. there isn't browser-specific code). Both Firefox and Edge should follow the spec and treat forward-filling animations of the transform property as always having 'will-change:transform' specified (which then means they become a containing block for positioned descendants and they also mark a new stacking context). 

Another avenue worth exploring is moving the change in that CL from the generic HasTransformRelatedProperty to the specific functions for positioning and stacking context, and see if the bug reproduces. We had assumed that it was correct to make this change in HasTransformRelatedProperty (because will-change transform is there too, and this is equivalent), but perhaps we missed something.

I tried on Firefox and Edge, and they are both correct. I suspect inbox may have browser-specific code but can't be sure.

My concern with the former solution is that there might be other websites that have the same kind of browser-specific code, that is depending on this behavior as well, and we don't how many websites there are.

That's why I am in favor of latter solution. I tried locally by moving the check from HasTransformRelatedProperty to CanContainFixedPositionObjects and that did fix this bug.

By only modifying CanContainFixedPositionObjects, you have removed the stacking context behavior - that is not correct by spec afaik. Please also modify the stacking context function and re-test.

Ah, I see your point.

Right, if we put the check in UpdateIsStackingContext, that will comply with the spec, but break inbox. It does sound like there is browser-specific code.

> if we put the check in UpdateIsStackingContext, that will comply with the spec, but break inbox

Have you confirmed this, or is it speculation? Please confirm.

> It does sound like there is browser-specific code.

Or there is a stacking context bug in Chrome, which Inbox did not previously expose but does now. We don't have enough information here yet.

It is very likely true (given the bisect), but have we confirmed that a forwards-filling animation is involved in the reproduction? Have we started paring down the reproduction to try and minimize it? When it does occur, is it stable (e.g. can we pull open devtools and examine things whilst it is still reproducing) or is it transient?

This is a bug (in the browser, not inbox).

With devtools I was able to make the problem go away by toggling off and on some will-change declaration higher up in the tree. I failed to narrow it down to a simple testcase, so I don't remember the details.

Xida and I looked at this for a few hours this morning. We made some progress, but not much given our lack of experience with stacking contexts. Let me try to summarize what we observe, but first an ask:

Inbox team - is it possible to get Inbox to serve non-minified JS? Having real class names/etc is very useful when trying to debug this sort of thing. Thanks!

-----------------------------

The DOM structure of a particular expanded email is as follows:

email
 |
 - subject div
 |  |
 |  - ... (multiple layers)
 |    |
 |    - snooze window (normally display:none)
 |
 - body-and-reply div
     |
     - body div
     |
     - reply div
    
So on a DOM level, the body and the reply are both after the subject (and the snooze window), and so should paint on top of them. However clearly in the working case the snooze window paints on top (see attachment1_stable.png). This is because the snooze window is a stacking context (it is position: absolute and has a non-zero z-index).

In the broken case, the body and reply are painting above the snooze window (see attachment2_broken.png). The only reason we can see the snooze window is that the body has a transparent background. Making it black makes the painting order clear (see attachment3_broken.png).

My assumption is that we have given the body and reply a stacking context, which is causing them to paint on-top of the snooze window. The DOM is complex enough that we haven't been able to prove this yet, but Xida has started adding some logging to a local client to try and figure it out (both if this is true, and if so whether it is expected or a bug in Chrome).

I welcome input/suggestions on debugging stacking contexts, as I am unfamiliar with this area. cc a few folk who may be familiar

Deleted: attachment1_stable.png 45.2 KB

	attachment1_stable.png 45.2 KB View Download

Deleted: attachment2_broken.png 29.4 KB

	attachment2_broken.png 29.4 KB View Download

Deleted: attachment3_broken.png 19.6 KB

	attachment3_broken.png 19.6 KB View Download

(Just realized this wasn't filed by the inbox team originally, whoops. I'll reach out internally to try and find out how to get an unminified page).

Some more outcomes from conversations with flackr:

  * The layers panel looks weird for both stable and canary; unclear if much information can be gleaned from this.
  * Trying to take a static dump fails; it doesn't repro (assuming due to lack of animations)
  * We suspect that perhaps our logic for adding the bit to the computed style is incorrectly holding onto the bit after the animation is removed from the style (just a theory).

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

commit 86dea917da54db1ecfd9acb4d13f79e5ec134ed6
Author: Xida Chen <xidachen@chromium.org>
Date: Mon Nov 12 21:40:50 2018

Do not enable stacking context with transform animation + some fill mode

In our previous CL:
https://chromium-review.googlesource.com/c/chromium/src/+/1066630
We make an element containing block and enable its stacking context when
this element has transform animation with forwards or both fill-mode.
This change is breaking the stacking context behavior where inbox
depends on.

This CL keeps the containing block behavior but reverts the stacking
context. Unit tests are updated.

Bug:  899759 
Change-Id: I1f519c3383df9a89bcd0c2ec9f15e1c9b8ca1dc0
Reviewed-on: https://chromium-review.googlesource.com/c/1330282
Reviewed-by: Stephen McGruer <smcgruer@chromium.org>
Reviewed-by: Anders Ruud <andruud@chromium.org>
Commit-Queue: Xida Chen <xidachen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607336}
[modify] https://crrev.com/86dea917da54db1ecfd9acb4d13f79e5ec134ed6/third_party/blink/renderer/core/animation/compositor_animations_test.cc
[modify] https://crrev.com/86dea917da54db1ecfd9acb4d13f79e5ec134ed6/third_party/blink/renderer/core/style/computed_style.h

Thank you!