Thanks for filing the issue!

Able to reproduce the issue on reported chrome version 71.0.3578.98 and on the latest canary 73.0.3678.0 using Mac 10.14.1. As the issue isn't seen on M60(60.0.3112.0) adding label Needs-Bisect, Will update the bisect info soon.

++ Issue is also seen on Windows 10 and Ubuntu 14.04.

Bisect Information:
-------------------
Good Build: 61.0.3136.0
Bad Build:  61.0.3137.0

Providing With Chromium Bisect as we are facing Errors while performing per-revision bisect.
You are probably looking for a change made after 480770 (known good), but no later than 480774 (first known bad).
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/ae671d82d797e89ff5e78a2bd26b850289ee59e4..320fda426653eb580beff6bc539e117f6a685a2a
Suspecting: https://chromium.googlesource.com/chromium/src/+/320fda426653eb580beff6bc539e117f6a685a2a
Review URL: https://chromium-review.googlesource.com/538658

@Morten Stenshorne: Please help in assigning it to the right owner if this isn't related to  your change.
Note: Assigning it to ID mstensho@chromium.org as mstensho@opera.com isn't in use.

Thanks!

Reverting the suspected CL fixes this bug, so that was the right CL alright.
Attaching simplified test. This already works fine in LayoutNG, BTW.

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

commit c74803336056e95d41eab4adcbabf6f19c951dc3
Author: Morten Stenshorne <mstensho@chromium.org>
Date: Tue Jan 22 21:12:25 2019

Recalculate preferred widths on layout when necessary.

Some objects take the size of the containing block as input when
calculating preferred inline-size, contrary to common sense; see the
NeedsPreferredWidthsRecalculation() documentation in LayoutBox.

In such cases we may need to recalculate the preferred inline-size as
part of layout, even if no content inside changed. At the same time, we
need to be careful not to do unnecessary work here. There is an
optimization that just refuses to update preferred inline-size if it was
already marked dirty, because the assumption then is that the preferred
inline-size will in fact never be needed. This optimization caused
trouble for the other optimization, which checks if the containing block
also is a special object that needs this kind of preferred inline-size
calculation as part of layout, because if it does, the idea is that the
containing block will already have taken care of it as part of walking
the subtree. The missing part here was to check if the containing block
actually would calculate its preferred inline-size at all (or if it was
skipped due the first optimization). Fixed that.

Bug: 923568
Change-Id: I66064ee46de4769c9dc25d7ade727f6ccdc5d7c6
Reviewed-on: https://chromium-review.googlesource.com/c/1426677
Commit-Queue: Emil A Eklund <eae@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Cr-Commit-Position: refs/heads/master@{#624919}
[modify] https://crrev.com/c74803336056e95d41eab4adcbabf6f19c951dc3/third_party/blink/renderer/core/layout/layout_box.cc
[add] https://crrev.com/c74803336056e95d41eab4adcbabf6f19c951dc3/third_party/blink/web_tests/external/wpt/css/css-sizing/aspect-ratio-affects-container-width-when-height-changes.html