Search forms at fixed CONTAINER widths

Why this page exists. The widget CSS sizes from its own container, not the viewport — a widget in a 360px sidebar must lay out correctly on a 1400px monitor. Resizing a browser window tests the wrong variable, because on most harness pages the container simply tracks the viewport. Each widget below is locked inside a fixed-width box (dashed outline) so container behaviour is measured directly.

Built for #2503 (single-row widget header + progressive collapse) and #2759 (dropdown panels unreachable on narrow containers). Baseline capture — it shows current behaviour; nothing here is a proposed design.

Reading it: each label shows the intended width and the width the container actually reports at runtime. Anything spilling past a dashed edge is the widget failing to respect its container.


NLS search form — .nls-toolbar (the pill row)

Per #2503 this is where NLS belongs: standalone search forms and quicksearch. Watch the pill row wrap rather than fold into MORE, and note the order things move in.

container 1200px
container 900px
container 768px
container 600px
container 480px — below the 599px rule
container 360px — sidebar case

Area-search form — .mbb-form-search (the legacy header)

Per #2503 this is what Results / Map headers use. Same widths, for direct comparison — this is the surface the single-row spec would be ported onto.

container 1200px
container 900px
container 768px
container 600px
container 480px
container 360px — sidebar case

Scroll rig for #2759

#2759 only reproduces when the toolbar sits low in the viewport. The panel's top is latched at open time from its static position in document coordinates, so at scroll 0 it is exactly correct — which is why an unscrolled test passes. Scroll past the filler, then open a pill on the narrow form below.

scroll past this, then open a filter pill below
container 420px — open a pill here, after scrolling
filler, so the rig above can sit low in the viewport