Description
content-actions.spec.ts:349 asserts that the publication-date trigger keeps
its label on one line:
expect(publicationDateLayout).toEqual({ height: 36, labelLines: 1, valueLines: 1 });labelLines counts Range.getClientRects() over the label's contents, but the
label carries Kumo's truncate, which is white-space: nowrap, so it can
never occupy two lines. A second rect appears when Chromium fragments an
ellipsized text run, so the assertion in practice reads "the label is not
ellipsized".
Whether it is ellipsized depends on its sibling. The label is flex-1 with
truncate and the value block is shrink-0
(PublishingDateTimeEditor.tsx:607,610), so the value takes the width it needs
and the label absorbs what is left. That value is a publication date formatted
during the test, so its width follows the clock.
I saw this on a documentation-only PR that changes no admin code. Just before
01:00 UTC on 2026-09-10 the assertion failed in both E2E tests (2/8) and
E2E Cloudflare (2/8), on the first attempt and the retry alike, with the
value at Sep 10, 2026, 12:54 AM and 12:55 AM respectively. A run eleven
minutes later on another branch that leaves the admin untouched passed; by
then the hour had rolled over to 1, one character narrower than 12.
The assertion arrived on 2026-09-06 in #2891, and every run between then and
2026-09-09 fell on a single-digit day, one character narrower again.
Steps to reproduce
This mirrors the trigger's markup at the width the test forces and counts rects
the same way:
<body>
<style>
body { font-family: ui-sans-serif, system-ui, -apple-system, "Segoe UI",
Roboto, sans-serif; }
.btn { width: 296px; height: 36px; overflow: hidden; white-space: nowrap;
padding: 6px 8px; box-sizing: border-box; }
.row { display: flex; width: 100%; min-width: 0; align-items: center; gap: 8px; }
.label { flex: 1 1 0%; min-width: 0; text-align: start; font-size: 14px;
overflow: hidden; text-overflow: ellipsis; white-space: nowrap; }
.value { display: flex; flex-shrink: 0; align-items: center; gap: 6px;
white-space: nowrap; font-size: 14px; }
</style>
<script>
for (const v of ["Sep 10, 2026, 12:54 AM", "Sep 10, 2026, 1:05 AM"]) {
const btn = document.createElement("div");
btn.className = "btn";
btn.innerHTML = '<span class="row"><span class="label">Publication date</span>' +
'<span class="value"><time>' + v + '</time><svg width="12" height="12"></svg></span></span>';
document.body.appendChild(btn);
const label = btn.querySelector(".label");
const range = document.createRange();
range.selectNodeContents(label);
console.log(v, range.getClientRects().length, label.scrollWidth > label.clientWidth);
}
</script>
</body>In Chromium this logs 2 true then 1 false; the second value is a narrower
one for contrast, not one read off a run. system-ui resolves differently on a
runner than on a desktop, so the exact cut-off moves. The point is that the
rect count follows the value's width.
Environment
- emdash version:
main at 44114afd
- Node.js version: the CI default in
ci.yml
- Runtime: both Node and Cloudflare shards
- OS:
ubuntu-latest, chromium
Screenshots
Logs / error output
Error: expect(received).toEqual(expected) // deep equality
- Expected - 1
+ Received + 1
Object {
"height": 36,
- "labelLines": 1,
+ "labelLines": 2,
"valueLines": 1,
}
at e2e/tests/content-actions.spec.ts:349
Description
content-actions.spec.ts:349asserts that the publication-date trigger keepsits label on one line:
labelLinescountsRange.getClientRects()over the label's contents, but thelabel carries Kumo's
truncate, which iswhite-space: nowrap, so it cannever occupy two lines. A second rect appears when Chromium fragments an
ellipsized text run, so the assertion in practice reads "the label is not
ellipsized".
Whether it is ellipsized depends on its sibling. The label is
flex-1withtruncateand the value block isshrink-0(
PublishingDateTimeEditor.tsx:607,610), so the value takes the width it needsand the label absorbs what is left. That value is a publication date formatted
during the test, so its width follows the clock.
I saw this on a documentation-only PR that changes no admin code. Just before
01:00 UTC on 2026-09-10 the assertion failed in both
E2E tests (2/8)andE2E Cloudflare (2/8), on the first attempt and the retry alike, with thevalue at
Sep 10, 2026, 12:54 AMand12:55 AMrespectively. A run elevenminutes later on another branch that leaves the admin untouched passed; by
then the hour had rolled over to
1, one character narrower than12.The assertion arrived on 2026-09-06 in #2891, and every run between then and
2026-09-09 fell on a single-digit day, one character narrower again.
Steps to reproduce
This mirrors the trigger's markup at the width the test forces and counts rects
the same way:
In Chromium this logs
2 truethen1 false; the second value is a narrowerone for contrast, not one read off a run.
system-uiresolves differently on arunner than on a desktop, so the exact cut-off moves. The point is that the
rect count follows the value's width.
Environment
mainat44114afdci.ymlubuntu-latest,chromiumScreenshots
Logs / error output
Error: expect(received).toEqual(expected) // deep equality - Expected - 1 + Received + 1 Object { "height": 36, - "labelLines": 1, + "labelLines": 2, "valueLines": 1, } at e2e/tests/content-actions.spec.ts:349