To reproduce, you need to read the css property of a child element, after you've set its parent to "display:none" and then any changes to the grandparent seem to be ignored as though the child's values are being cached. 

If you comment out the line where I read the CSS property of the child before changing the grandparent, it works as expected:
https://jsfiddle.net/JoolsCaesar/1w9swvLa/5/

for bisect: https://jsfiddle.net/JoolsCaesar/1w9swvLa/

broken output:
Child on startup - visible
Child after display:none on parent - visible
Child after visibility:hidden on grandparent - visible
Child after poking Chrome - hidden

expected:
broken output:
Child on startup - visible
Child after display:none on parent - visible
Child after visibility:hidden on grandparent - hidden
Child after poking Chrome - hidden

I'm not able to reproduce this on master with content_shell. What looks suspicious is the conditional clearComputedStyle() in Element::recalcStyle():

  if (change != IndependentInherit)
    data->clearComputedStyle();

because computedStyle() used in propagateInheritedProperties does not return computed style stored on RareData. It does work for me, however, because clearComputedStyle() is called from attach/detach and recalculating a display:none element always trigger a reattach**. I don't think not clearing the rare data computed style on inherited style propagation makes sense since it won't propagate to those computed style objects anyway.

It's possible that this was a regression, and recent changes in layout tree reattachments hid this issue.

** I don't see why that is necessary, but stylePropagationDiff does not detect that changing between a null ComputedStyle and a ComputedStyle with display:none does not require a reattach.

Able to reproduce the issue on Windows 10, Ubuntu 14.04 and Mac 10.11.6 using reported version #54.0.2840.59 but the same is not reproducible in the latest canary #56.0.2896.0.

Reverse Bisect Information:
=====================
Good build: 55.0.2875.0	

Bad build: 55.0.2874.0	

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/f615e0c9a4dc04ef8d360b57ff6c6df5d9b8ffe9..ae17e4f7001f6523d0e426028d842f436199fe0f

From the above change log possible CL that fixed this issue:

Review-Url: https://codereview.chromium.org/2380503002

bugsnash@ - 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.

Have confirmed that my patch is responsible for the fix - it reverted the patch responsible for the bug

As previously mentioned, the fix has already made it into dev.

Have decided not to merge the fix into beta at this point as it's not a critical regression or a crash issue and it seems like this isn't affecting sites in the wild. Will re-evaluate if there are future reports.

"it's not a critical regression or a crash issue and it seems like this isn't affecting sites in the wild"

I made a pretty contrived JSFiddle to keep the problem easy to understand, but I reported this, because I'm working on a web application that started leaving holes in its overlays because it thought that an element underneath it was visible, when it wasn't. Workarounds are easy enough, but anyone who has written applications that look at the computed CSS values, which previously worked in every browser, will now see them failing in Chrome, for reasons that aren't exactly easy to diagnose.

Hey joolschadwick! Unfortunately we won't be able to merge this fix into beta as it's not eligible under the merge policy (https://www.chromium.org/developers/the-zen-of-merge-requests). 

The policy states that the only merges that will be accepted into beta (ready for a push to stable) are "ReleaseBlock-Stable issues that fit the category of Security/Stability/Critical Regressions"

We haven't been able to find widespread sites affected, so we've decided to not to merge.

However the fix is already in the dev channel so will make its way to beta and stable as new releases are released.