Files
openobserve/scripts
Omkar Kesarkhaneandgithub-actions[bot] d6c726c222 fix(synthetics): show where recorded steps will land (#13860)
## What

Shows where recorded steps will land in a browser journey — as a
labelled divider above the target row, previewed on hover and held for
the whole recording session.

## Why

Each step row carries a Record control meaning "restore the journey up
to here, then record new steps before this row". It was the most
expensive click in the editor — it opens an incognito window and replays
every preceding step — and nothing said where the result would land
until after that had already started.

The only signal was a "Recording here" badge rendered inline in the
anchored row's details cell, between the action icon and the action
label. Sitting inside the row, it read as *this row is recording* when
it means *new steps go above this row*.

## What changed

- The badge is replaced by a divider on the row's top edge: two rule
segments with a centred label between them, straddling the boundary so
it names a position **between** rows rather than a property of one.
- Hovering or focusing a row's Record control draws the same marker in a
lighter tone, so the destination is legible while the click is still
free.
- The preview is suppressed wherever the control is disabled — the first
row, a locked table, or an extension too old to restore. A preview of an
action you cannot take is worse than no preview.
- Focus is bound alongside hover, so the affordance is not mouse-only.

Two edge cases surfaced while testing and are fixed here:

- A replay started from the toolbar locks the table while the pointer
rests on a row control. Nothing moves, so no `mouseleave` arrives, and
the preview sat on a locked table offering a click that was now refused.
- Both render modes share the details cell slot, so an anchor id
reaching results mode drew a marker on a finished run — over a cell with
no positioning to hold it.

## Implementation notes

No `OTable` change. The marker is absolutely positioned against the
details `<td>`, which becomes a containing block via the column's
`meta.cellClass`. Two consequences worth knowing:

- **Nothing reflows.** Toggling the marker on hover repaints only. A
rule that took layout would jitter the whole table as the pointer
crossed the action column.
- **The gap is real, not painted.** The label sits between two `flex-1`
segments rather than over a continuous rule. That centres it without
measuring anything, and means it needs no background to avoid being
struck through.

`getCellStyle` lifts the cell's `overflow: hidden` on the marked row
only, so the label can overhang the boundary. Step-name truncation is
unaffected — that ellipsis lives on the inner wrapper, not the `<td>`.

## Testing

- `JourneySteps.spec.ts`: 43 tests (18 new), covering the committed
marker, the hover and focus preview, suppression on every disabled path,
tone precedence when a committed anchor and a hover coexist, anchor
reassignment, the positioning contract, and results mode.
- Full journey suite green: 336 passed, 1 skipped,
`BrowserJourney.spec.ts` unmodified — which is what shows the marker
rides the existing `anchorId` prop rather than duplicating state.
- Guards were mutation-checked: deleting each one turns the suite red,
so none of them pass vacuously.
- `lint`, `type-check`, `format:check` and
`check-design-consistency.mjs` all clean.

## Not covered

jsdom has no layout, so positioning is pinned by class assertions only —
this has not been verified visually. Worth an eye on the label at the
dense row height, in both themes.

Out of scope, and unchanged by this PR:

- The marker does not survive into recording — `BrowserJourney` replaces
the whole journey table with a capture-only table while recording, so
there is no row to mark.
- The toolbar Record button draws no marker below the last row.
- Downstream steps keep stale pass ticks after a splice, and the passed
banner recomputes its total from the new step count.

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
2026-08-20 05:21:09 +00:00
..