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

commit 153c157836de9b1f20dbf809d4b7295e3c224531
Author: Xida Chen <xidachen@chromium.org>
Date: Fri Jan 04 15:14:04 2019

Disable measure-updated-layout.html on linux

Test is flaky

TBR=maxmorin@chromium.org
NOTRY=true

Bug:  919096 
Change-Id: I90e8113f1e1271ff9faaa6185bb34036916b2f4f
Reviewed-on: https://chromium-review.googlesource.com/c/1396222
Reviewed-by: Xida Chen <xidachen@chromium.org>
Commit-Queue: Xida Chen <xidachen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#619952}
[modify] https://crrev.com/153c157836de9b1f20dbf809d4b7295e3c224531/third_party/blink/web_tests/TestExpectations

So the issue seems to be that when we do Element::AttachLayoutTree on the container element, we don't create a layout object, and the display lock's update promise is rejected. This happens about 0.8% of the time for me locally.

The fix is easy enough:
replacing runTest(); with window.onload = runTest;

However, I'd like to understand why this is happening. +futhark do you by any chance know why we wouldn't create a layout object when we attach a layout tree? Essentially what we have is

<div id="parent"></div>
<script>
let container = document.createElement("div");
container.id = "container";
document.getElementById("parent").appendChild(container);
</script>

With container being styled to have size and content containment. If we delay the script block to be in an onload handler then everything seems to work.

If we don't create a layout object at that time, when would we create it? Or is this a misuse of code and layout object is never created?

You might have some race condition going on with your async runTest() and html parsing since the html parser may finish parsing the document before runTest() finishes. Finishing html parsing will cause a style/layout tree update here:

https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/document.cc?sq=package:chromium&g=0&l=6122-6123

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

commit e43c748762648c7104a5d33f33cae91be744b2b6
Author: Vladimir Levin <vmpstr@chromium.org>
Date: Mon Jan 07 15:56:28 2019

[PE,DL] Deflake a display locking test.

This test fails occasionally due to the fact that when we attach the
layout tree, the element doesn't have the layout object (yet). To fix it
ensure that this test (and another similar one) are run from an onload
handler.

For more information see the referenced bug.

R=chrishtr@chromium.org

Bug:  919096 
Change-Id: Id13f87c2d5c5720fd6fde0af1c74e7a0e70623bb
Reviewed-on: https://chromium-review.googlesource.com/c/1396494
Commit-Queue: vmpstr <vmpstr@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#620333}
[modify] https://crrev.com/e43c748762648c7104a5d33f33cae91be744b2b6/third_party/blink/web_tests/TestExpectations
[modify] https://crrev.com/e43c748762648c7104a5d33f33cae91be744b2b6/third_party/blink/web_tests/display-lock/lock-before-append/measure-forced-layout.html
[modify] https://crrev.com/e43c748762648c7104a5d33f33cae91be744b2b6/third_party/blink/web_tests/display-lock/lock-before-append/measure-updated-layout.html

Thanks for the explanation.. it was very likely that it was the parser race as you describe..