Able to reproduce on Windows-10 and Ubuntu 14.04 using chrome stable M57-57.0.2987.98. Mac OS 10.12 works fine.

Bisect Information:
=====================
Good build: 57.0.2972.0
Bad Build : 57.0.2974.0

You are probably looking for a change made after 441591 (known good), but no later than 441592 (first known bad).

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/cd8243b3c7f369202cffc7afcc2e75338de3da92..d3ba7664a7ebc6e74861602eb9696c7ca0a4ed2e

From the above change log suspecting below change
Review URL: https://codereview.chromium.org/2588853002

schenney@ - 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: Since this issue got regressed in chrome M-57 adding RB-Stable, Please feel free to edit if this is not the case.

Thanks!

The problem is not serious enough to warrant release blocking. But it is our 3rd M-57 paint regression.

The issue is specific to the text box, replacing it with a div gives the right behavior. And when the text box has the focus the behavior is also correct. This is very odd.

This is super odd. Taking the style property on the sibling div, and putting it in a <style> block with an associated class, causes the issue to go away. Why on earth would defining the property in a style block vs on the element cause a change in behavior?

Transforms applied inline to elements trigger a certain fast path in the
SPv1 compositor to make them faster. They avoid a full compositing state rebuild
and compensate by setting "assumes overlap" for everything later in paint order.

So a fix for this issue is always assuming overlap for elements with transparency? It suggests this is a squashing bug, where we are squashing and losing the opacity. It also explains why giving the element the focus modifies the behavior.

Or it might just be that we are missing something in the input elements that we have on other elements, since this only seems to hit input elements. The quest continues.

Two clarification:
a. It's not only a text-input. It could be any input element, e.g. submit, password.
b. Not only happens when inlined style on sibling element, but on any element on the same page can cause this issue.

Thanks for the extra info. I suspected it was a problem for all input and I appreciate you confirming that.

Not squashing related. In no case is a layer squashed thanks to SquashingDisallowedReasonClippingContainerMismatch

What is the layout tree like on Windows? I think we need a platform-independent
repro.

This fails on Linux. Will check Windows.

Deleted: input-element-opacity-when-masked.html 448 bytes

input-element-opacity-when-masked.html 448 bytes View Download

Fails on Windows too. Interestingly, when you turn on Show Layers in DevTools the input element gets its opacity again.

Dropping priority because:
(a) There's a workaround (do not inline style)
(b) It seems very rare to have transparent input elements (animating opacity to make an element disappear is probably the use case)

@schenney: do you need help figuring this out? May be a subtle issue deep somewhere.

I will likely need help if I determine that it is in fact a cc bug, otherwise I'm learning stuff.

Right now I've got to the point where the broken/unbroken cases differ at the GraphicsLayer level only by the presence of an "offset from layout object". i.e. I'm not at a dead end.

Probably duplicate of https://bugs.chromium.org/p/chromium/issues/detail?id=709081.