Packets: changing the type or observer filter drops ?obs= from a packet detail URL

[dborup]

Summary

On a packet detail URL such as #/packets/<hash>?obs=<observationId>, changing the packet-type or observer filter rewrites the hash to #/packets/<hash> (plus filter params). The detail pane keeps showing the selected observation, but the address bar no longer describes it: a refresh or a copied link opens the packet without that observation.

Verified by reading public/packets.js on master (9eb30988); not reproduced in a running instance.

Steps to reproduce

1. Open a packet with an explicit observation, e.g. #/packets/<hash>?obs=123 (the form the detail pane's own links produce).
2. In the filter bar, tick a packet type (or an observer).
3. Look at the address bar: ?obs=123 is gone. Refresh: the packet opens with its default observation, not 123.

Cause

updatePacketsUrl() (public/packets.js, around line 769) does two things:

• rebuilds the hash as #/packets + subpath + buildPacketsQuery(...), and
• shows or hides the Clear Filters button.

buildPacketsQuery() (around line 748) only emits filter state (timeWindow, region, hash, node, observer, channel, filter, sort). Detail-view params such as obs are parsed from the route (around line 1156) but never written back, so every call drops them.

The observer menu handler already called updatePacketsUrl(). #2015 (Clear Filters, merged 2026-09-13) added the same call to the type menu handler so the Clear button becomes visible with only a type selected, which extends the behaviour to type changes.

Suggested fix

Either of:

1. Split the Clear-button visibility into its own function and call only that where the URL does not need to change (the type menu: type is not part of the URL).
2. Make updatePacketsUrl() preserve detail-view params it does not own (at least obs) when rebuilding the query, which fixes all filter handlers at once.

A regression test that starts on #/packets/<hash>?obs=123, changes type and observer, and asserts that obs=123 survives would pin either fix. The existing Clear Filters tests start on plain #/packets, so they cannot catch this.

Context

Found while porting #2015 to a downstream fork; an independent review there flagged it before merge. The fork is fixing its port with option 1.

[dborup]

One more call site with the same effect, found while testing a fix for the type menu: init() calls updatePacketsUrl() on page load to show the Clear button when the URL carries filters (in public/packets.js, right after the filter-bar handlers are wired). So opening #/packets/<hash>?obs=123 directly already rewrites the address bar to #/packets/<hash> before any click. ?obs has been parsed by then, so the first render still shows observation 123, but a second refresh or a link copied from the address bar loses it.

That makes option 2 above (let updatePacketsUrl() keep detail-view params such as obs when it rebuilds the query) the more complete fix, since it covers load, the type and observer menus and the other filter handlers in one place.