Need to explore what browser/operating system/bandwidth combinations the Explore works and does not work in

[akthom]

We are observing some performance differences for the Explorer that might be due to differences in browser/operating system/bandwidth combinations. For instance, I'm using Firefox on a macbook, and the Explorer doesn't seem able to load some searches that are able to load on other people's systems. here's a screen shot:

When I try to combine two material facets, the explorer chokes and just displays "--" next to the facet counts. But Eric and Raymond were both able to load this search and get correct counts.

Could you explore whether there are browser/operating system combinations that can't run the explorer efficiently? And if there's a recomended minimum amount of bandwidth/ internet connectivity needed to run the explorer? And recommend what browser the explorer works best in? users should be able to click multiple facets on and off without the explorer crashing. They should be able to spin the globe around without it breaking.

[rdhyee]

Investigation: the "--" is the honesty-dash; root cause is a boot-time loading race

Thanks @akthom — we traced this. The "--" you see isn't a crash; it's a deliberate "honesty" signal added in the recent facet-count work (#304/#305/#308): when the Explorer can't yet compute correct cross-filtered counts, it shows a dash instead of a wrong number. So your dash means the count-index wasn't ready (or failed to load) at the moment you applied the 2nd material facet.

Most likely root cause — a boot race (slow connection / Firefox)

Before multi-filter counts work, the page must download and scan ~20 MB of count data at boot (sample_facet_masks 9.7 MB + the new sample_facet_index 9.7 MB, the latter via a full-table scan coverage check). On a modest or throttled connection — or a backgrounded Firefox tab, where network/timers are throttled — that takes 20–80+ seconds. If you select the 2nd facet inside that window, the count path returns "not ready" → the dash.

• It auto-recovers once loading finishes (counts fill in on their own) — unless the preflight throws (network error / DuckDB-WASM hiccup), in which case the dash is permanent for that session and a refresh is needed.
• This compounds with explorer: 60–90 s 'no dots' window on cold-cache deep-link to point mode (DuckDB-WASM 1.24.0 falls back to full HTTP read) #190 (DuckDB-WASM 1.24.0 sometimes "falls back to a full HTTP read" instead of fetching byte-ranges), which is worse in Firefox Workers.

Transparency: the #305 work we just shipped roughly doubled the cold-boot download budget (it added the 10 MB index + a full-scan coverage check to the critical path). So part of this is self-inflicted and fixable on our side.

Reproduce it (no Firefox needed)

DevTools → Network → throttle Slow 3G → hard-refresh → immediately apply 2 material facets at world zoom → "--" appears. Console: "sample_facet_index preflight failed" = permanent dash; silence = timing race that auto-recovers after the load finishes.

Prioritized fixes (full analysis attached internally)

• P0 (easy): show "Loading count data…" instead of an instant "--", so you know to wait (and it auto-fills).
• P1 (medium): drop the full-scan coverage check (tiny meta file instead) → critical path ~20 MB → ~0.5 MB, which mostly closes the race.
• P2: upgrade DuckDB-WASM (better range handling; ties to explorer: 60–90 s 'no dots' window on cold-cache deep-link to point mode (DuckDB-WASM 1.24.0 falls back to full HTTP read) #190).
• P3: decouple the index preflight from the masks scan.
• P6 (easy): enable Firefox in our Playwright CI — would have caught this at merge time.

We're evaluating P0–P6 now and will start with at least P0 (and the rest pending review). Minimum-bandwidth / best-browser guidance will come out of the live testing in your three browser/OS/bandwidth questions.

— 🤖 rbotyee+CC; static analysis + curl/duckdb probes against production data; RY reviewed