### Overview The Cypress test `Prop types editing › Date + Time widget` (`web/modules/contrib/canvas/ui/tests/e2e/prop-types.cy.js:244`) fails intermittently on CI. After typing a new date and time, the test waits for the preview iframe to show the new value, but the preview keeps the old time and the assertion times out: ``` Timed out retrying after 4000ms: [data-test-canvas-content-initialized="true"][data-canvas-swap-active="true"] in iframe includes text 2017-06-28T19:21:35.000Z: expected 0 to be above 0 ``` Example job: https://git.drupalcode.org/project/canvas/-/jobs/10055400 The root cause is a race in the test, not the application. Two things combine: 1. The test focuses the time input and types, but never blurs it. A native `<input type="time">` only fires the `change` event — which drives the preview update — when its value is committed (blur/Enter). So the time's `change` never fires; the preview reflects the new date (committed when focus leaves it) but not the new time. 2. Even once committed, the preview re-renders asynchronously: the edit triggers a debounced `PATCH /canvas/api/v0/layout/node/{id}` and the iframe is re-rendered only when that response lands. The original test waited on the iframe with the default 4s timeout, which races that round-trip. (The date+time form-value assertions pass, so only the preview assertion fails.) ### Proposed resolution - Blur the time input after typing so its `change` fires the preview update. - Synchronize on the application's own signal instead of a timeout: wait until the `PATCH /canvas/api/v0/layout/node/{id}` whose payload carries the new time value has *completed* (its response landed) — that request is what re-renders the preview — and only then assert the iframe. This reuses the intercept + `@alias.all` payload-inspection pattern already used by `assertMultivalueReorder`. Validated locally with 5/5 clean first-attempt runs (no retry rescue). ### User interface changes None.