mirror of
https://github.com/openobserve/openobserve.git
synced 2026-11-04 08:09:27 +00:00
## 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>