internetarchive / internetarchive/openlibrary

Advanced Search discards the current query and any selected filters

Open
#13,488 4 comments 0 reactions 1 assignee Claimed by @Utkarsh3725 View on GitHub
Affects: UI Good First Issue Lead: @cdrini Module: Search Page(s) Needs: Response Priority: 3 Theme: Search Type: Bug
Dominant language
Python
Stars
6.7k
Forks
2k
Avg merge
2d 19h
Merged PRs (30d)
138

Description

### Problem

Every tab in the search navigation carries the current query forward except Advanced Search, which links to a bare `/advancedsearch`. The form on that page also reads nothing from the request, so a patron who has built up a search and wants to refine it more precisely lands on an empty form and starts from scratch.

It's the one place in the search flow where state is dropped rather than carried, and it lands on the patron most likely to want it — someone whose search is already specific enough that they've gone looking for the advanced form. The form posts back to `/search`, so it's meant to be part of the same loop.

### Reproducing the bug

1. Go to https://openlibrary.org/search?q=quantum+entanglement&subject_facet=Physics
2. Click "Advanced Search" in the tab strip under the "Search Books" heading

* Expected behavior: the Subject field is prefilled with "Physics", and the free-text query is preserved
* Actual behavior: every field is blank and the query is gone; the Physics filter that was visible as a chip a moment earlier has vanished, with no way back to it except the browser's back button

### Context

- Browser (Chrome, Safari, Firefox, etc): any
- OS (Windows, Mac, etc): any
- Logged in (Y/N): N
- Environment (prod, dev, local): prod

### Breakdown

#### Related files

* `openlibrary/macros/SearchNavigation.html` — line 28. The other five tabs build their href as `/search/...?$urlencode(dict(q=q))`; this one is a bare `href="/advancedsearch"`.
* `openlibrary/templates/search/advancedsearch.html` — no `value=` bindings anywhere, so the form renders empty regardless of what's in the URL.

#### Note for maintainers

Four of the visible fields map straight onto search-page facets: `subject`/`subject_facet`, `person`/`person_facet`, `place`/`place_facet`, `publisher`/`publisher_facet`, plus `author`/`author_facet`. The free-text query is a little different, since `q` is a hidden input with no visible control — carrying it through would preserve the patron's text search without showing it back to them, which may or may not be what you want.

So this isn't quite a one-liner, and I didn't want to assume the answer: is it just `q`, or the facets too? Happy to pick it up either way once that's decided.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.