jaegertracing/jaeger-ui

Requirement We could add a few useful actions to the span row, shown only on hover collapse collapsible children of the current span focus subtree - makes the current span look like the root of the trace, with "reset" button (same icon but maybe crossed out and colored as active) added to the span permanently the More actions... menu adds "Copy deep link" and "Copy span ID"

What happened? On the Trace page, when the view selector dropdown ("Trace Timeline", "Trace Graph", etc.) is open, pressing Up/Down arrow keys does not navigate between the dropdown options. Instead, the arrow key events fall through to the SpanGraph minimap component behind the dropdown, causing the visible time window to resize unexpectedly. The only way to navigate between dropdown options via keyboard is to press Tab repeatedly through each item individually, which is non-standard and significantly slower than the expected arrow key navigation. Steps to reproduce Open any trace in Jaeger UI. Press Tab until the "Trace Timeline" button (top right) receives focus. Press Enter or Space to open the dropdown. Press the Down arrow key. Expected: focus moves to the next option (e.g. "Trace Graph"). Actual: the minimap timeline scrubber resizes instead - a completely unrelated component is affected. To navigate between options at all, the user must press Tab again to move through each

What happened? On the System Architecture page's DAG view, right-clicking (or clicking) a service node and selecting "View traces" opens a new tab to the Search page, but the search fails with a 400 error. This happens because handleViewTraces in DAG.tsx builds the search URL with only the service param. No lookback, start, or end is included. SearchTracePage has existing logic (in searchQueryFromUrl) to derive start/end from a lookback param when only lookback is present - but since this URL has no lookback either, that derivation never runs, start/end stay empty, and the backend API call fails with a 400. Steps to reproduce Run a local Jaeger backend with some multi-service trace data (e.g. via the HotROD demo). Go to the System Architecture tab. Click on any non-focal service node (e.g. customer) to open its context menu. Click "View traces". Observe: a new tab opens to /search?service=customer and shows: Failed to fetch trace summaries: 400 Bad Request Expected behavior Clicking

Requirement Ability to override the default timeout of 10s for requests sent to the Jaeger backend. Problem Ideally requests sent to Jaeger Backend should be fast and never take more than 10s which is the default timeout, but for more heavy queries those might take a longer time to process, otherwise they will fail. Proposal Provide an ability to override the Jaeger UI timeout potentially via the ui-config.json configuration file Open questions No response

Problem TracePage currently owns the search/find logic for all view types. It computes traceDagEV (the graph DAG), calls filterSpans for timeline views, and calls getUiFindVertexKeys for the graph view — all in the parent component. This means: The parent must hold internal data structures (traceDagEV) that belong to child views. Adding a new view that supports search requires modifying TracePage to add another branch in the search computation block. The parent has intimate knowledge of how each view searches, not just that it supports search. Related: hideMap and navigable were recently addressed with helper functions (viewTypeShowsMinimap, viewTypeIsNavigable), but search is the bigger coupling issue. Proposed Solution Use a callback prop (push model) so each view owns its own search logic and reports results upward. The data flow is fully declarative/reactive: The parent passes uiFind (the search query string) down as a prop — it already does this today. Each view recomputes