Cannot edit current search with new search bar

[w-biggs]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Code Search and Navigation

Body

Today, the search bar has changed significantly so that it's (sometimes) much smaller at the top of the page and a modal opens when you click it. With these changes, there is no way to edit the current search terms. If I have a long search and want to add something to it to refine the search, I now have to either type the entire search back in or manually edit the current URL instead. I also cannot see what the current search was without looking at the URL or clicking the search bar and looking at the most recent item.

This is what I see now after searching for "repo:angular/angular this is a long search query"

And if I want to edit that search, I have to re-type the entire thing -- there's no way to just edit my current search. This is what I see when I open the modal:

Clicking that top recent item just triggers a search with that query -- it doesn't populate the text box or anything. There's literally no way to refine a search without typing it all in all over again anymore.

This seems like a really poor UX decision that goes against how search bars work on every other website if it's on purpose, so I'm assuming it's a bug. I think this began today, or within the last week at least. I don't see anything related in the changelog.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[TranscranialAvenue]

Confirming I'm experiencing the exact same issue. The top search bar no longer displays
my current search query—it just shows the placeholder "type / to search" even when
viewing active search results.

Reproduction:

• Perform any search on GitHub
• Navigate to the results page
• The search field at the top still shows "type / to search" instead of the query

Environment:

• Reproducible across multiple browsers (Chrome + Vivaldi)
• Occurs whether logged in or not
• Affects all search result pages (code, repos, issues, etc.)

Workaround:
For now, I can edit the search query directly in the browser URL bar (modifying the
q= parameter in the URL) to refine searches without relying on the search field UI.

This is a clear regression—the search bar used to display/retain the active query for
quick editing. The functionality works when you click the field and type, but the visual
feedback of the current query is missing.

@github/support — flagging for triage. This appears to be a widespread UX regression
affecting multiple users.

[ntessman-capsule]

This is a wild product decision. Even if the search text did populate properly, hiding the input behind a modal dialogue activated by a click or key stroke doesn't improve or streamline the UX in any way. It's worse than useless.

ETA: There's already the command palette feature preview that is a modal hidden behind a key stroke that supports search. What exactly is the purpose of making a second, worse version of the same thing that was unceremoniously tested on end users without ever being behind a feature flag?

[memchr]

The filter autocomplete and highlighting features are gone too.