3 Commits
Author SHA1 Message Date
catarrh e0134c769a Command filter: multi-select with conversation presets (v2.7.0)
- the single-command <select> becomes a checkbox dropdown: the filter is a
  set of entries (an empty set shows everything), so any number of commands
  can be shown at once instead of one
- three fixed presets select whole conversations:
  * Proactive sessions — FETCH, TERMINAL PROFILE and every command the card
    answered with SW 91xx (the proactive-session initiators)
  * Proactive + events — the same plus ENVELOPE
  * File operations — SELECT, READ BINARY, READ RECORD, UPDATE BINARY,
    UPDATE RECORD (their GET RESPONSE, which carries the data/FCP, comes
    along through the existing response_for linkage)
  presets and single commands combine as a union, and the menu lists the
  session's commands with their counts
- the button summarises the selection ("All commands" / one name /
  "{n} commands"); Escape or a click outside closes the menu; focusing an
  APDU from the Files panel/map still clears the filter first
- tests: a new filter test (the matching rules per entry kind, the GR
  linkage, the presets, the union, the summary, the menu rows, the RU keys
  and the wiring pins), and the focusMessage tests follow the new state;
  527 Python + 72 Node tests
- README/README_RUS describe the filter; PWA_VERSION/pyproject/version.py
  2.7.0, SW cache simtrace-analyser-v80
2026-10-17 23:55:28 +03:00
catarrh 76c5647dd4 Files view: the jumped-to record stays selected (v2.6.2)
- focusMessage()/scrollToType() highlighted the target and removed the class
  after 1500 ms, so a Files-row (or map/category) jump looked selected for a
  moment and then lost it; on top of that any re-render (the 500 ms live
  poll, a filter/search change) rebuilt the list and dropped the highlight —
  even for a clicked entry
- the selection is now persistent app state (STATE.selectedIdx): the render
  marks the entry (gap rows included), focusMessage records the index before
  rendering, showDetail records it for plain clicks, scrollToType persists it
  too (clearing the previous highlight), and a new session/capture resets it
  so a stale index cannot mark an unrelated APDU
- tests: a stub-driven focusMessage case (state + detail updated, no render
  and no timer), the filter-clearing case, and source pins for
  renderMessages, focusMessage, scrollToType, showDetail, loadSession and
  startCapture; 527 Python + 58 Node tests
- README/README_RUS: the jump leaves the record selected; PWA_VERSION/
  pyproject/version.py 2.6.2, SW cache simtrace-analyser-v76
2026-10-17 23:16:33 +03:00
catarrh 08a6446bc8 Files view: the row jump no longer scrolls to the end of the trace (v2.6.1)
- jumpToMessage() rendered the APDU list through the unqualified
  renderMessages(), whose tail pins the view to the bottom (the live-capture
  stick), and only then let focusMessage() smooth-scroll back up to the
  clicked record — the visible jump-to-end-then-back.  It now renders with
  skipScroll, so the only scroll is the focus itself
- the content-follow became conditional: shouldStickToBottom() pins the view
  to the newest messages only while the reader is already at the bottom
  (40 px slack), so the 500 ms live poll no longer pulls away a view the
  reader scrolled to — a Files/map jump is no longer yanked down by the next
  batch.  A freshly opened session or a new capture still lands at the
  bottom (renderMessages(false, true))
- tests (node): the jump's paging/render(true)/focus sequence with stubs, the
  no-session no-op, the stick decision (at bottom / within slack / scrolled
  up / explicit jump / forced / first render) and source pins for
  renderMessages, jumpToMessage, loadSession and startCapture; 527 Python +
  53 Node tests
- README/README_RUS note the follow behaviour; PWA_VERSION/pyproject/
  version.py 2.6.1, SW cache simtrace-analyser-v73
2026-10-17 23:01:40 +03:00