Issue is reproducible in chrome canary also.
Working properly till Chrome 69.

The bug requires having the browser window height smaller than the modal.

Bisect info: 595575 (good) - 595585 (bad)
https://chromium.googlesource.com/chromium/src/+log/f35338b7..259427f1?pretty=fuller
Suspecting r595576 = aa14bd3327d6d299d310f13fb900fdd636e30817 = https://crrev.com/c/1253063 by chrishtr@chromium.org
"[PE] Don't consider "unclipped_descendants" from being conditioned on having a composted scrolling ancestor."
Landed in 71.0.3569.0
Merged to 70.0.3538.49

woxxom, I don't know who you are but your comments are frequently very helpful. Thank you! Do you have the permissions to assign bugs? In a case like this where we have a fairly likely regression change, I think it's fine to either cc or mark the bug as owned by the patch author.

We are experiencing a similar issue on Reddit. For some of our posts, they action bar (located below the post with a number of buttons, ie Comment, Share, Save) is not visible, however a user can still click on the button. Depending on the browser width the action bar will appear or disappear. It also is only affecting some types of post.

Steps to Reproduce:
In v70 visit reddit.com/r/highqualitygifs (in the redesign)

Scroll down in card view and observe posts missing the action bar. If you see button action bar then try resizing the browser window until they disappear. 

Attached is a screenshot of the buttons missing below the gifs

Screenshot attached of missing action bar

Deleted: action_Bar_missing.png 683 KB

	action_Bar_missing.png 683 KB View Download

We were able to fix the issue with the following change

  // Workaround for mysterious issue in Chrome 70 when all
  // flatlist buttons become invisible on specific screen width
  overflow-y: auto;

I can't reproduce the issue on Reddit, assuming you deployed the change
already?

The URL reported in comment 0 no longer works. Bug reporter, could you please
put up a page that reproduces the issue so I can debug it?

Ok now the comment 0 URL is back up...

Yes we deployed the change, but you can still reproduce the issue if you disable the workaround. see the attached screenshot

Deleted: Screen Shot 2018-11-09 at 2.48.55 PM.png 1.7 MB

	Screen Shot 2018-11-09 at 2.48.55 PM.png 1.7 MB View Download

Reduced testcase for #0 attached. The bisect is correct, but I think it is just
revealing an independent underlying issue that can be triggered in other ways.

Deleted: test.html 582 bytes

test.html 582 bytes View Download

I can't reproduce the suggestion in #9 on Chrome 70 or tip-of-tree Chrome.

For the #9 - The exact chrome version is 70.0.3538.77 (Official Build) (64-bit), MacOS High Sierra.

This bug is impacting lot of our customers.
When can we expect a fix?

Issue is still reproducible in 
Chrome Version 70.0.3538.102 (Official Build) (64-bit).

Still working on a fix. Will update soon.

I think the root issue is that a non-composited scroller can be nested inside
of a composited one. Even in that case, we should consider
has_non_root_composited_scrolling_ancestor to be true. I have a patch that
does that written and am adding a test now.

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

commit 4fe211a902905e0bace3144d1d8fef13b7395493
Author: Chris Harrelson <chrishtr@chromium.org>
Date: Thu Nov 15 16:02:59 2018

Look recursively for composited scrollers, not just stopping
at the enclosing scrolling ancestor.

Bug:  903067 
Change-Id: Ice5deb0047862fa72a47e34b1f54f6a6955ae56c
Reviewed-on: https://chromium-review.googlesource.com/c/1336784
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608382}
[add] https://crrev.com/4fe211a902905e0bace3144d1d8fef13b7395493/third_party/WebKit/LayoutTests/compositing/overflow/non-composited-scroll-inside-composited-fixed-position-expected.html
[add] https://crrev.com/4fe211a902905e0bace3144d1d8fef13b7395493/third_party/WebKit/LayoutTests/compositing/overflow/non-composited-scroll-inside-composited-fixed-position.html
[modify] https://crrev.com/4fe211a902905e0bace3144d1d8fef13b7395493/third_party/blink/renderer/core/paint/compositing/compositing_requirements_updater.cc

The fix will roll out in Chrome 72, which will reach the stable channel in
January.

In the meantime, you can work around the issue by putting "will-change: transform" css on the table elements.