[BUG] Switch to POST queries on {noai.,}duckduckgo.com breaks browser backwards history navigation #285
Labels
No labels
bug
confirmed
contribution welcome
duplicate
enhancement
good first issue
help wanted
important
invalid
other
question
upstream
web compat
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
celenity/Phoenix#285
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Confirmation Checklist
Releasespage.What web browser(s) are you using with Phoenix?
Firefox
Other
No response
What operating system(s) are you experiencing this issue on?
Ubuntu, Windows
Other
No response
What version of Firefox/Gecko and Phoenix are you using?
Firefox 150.0.1 (Phoenix: 2026.04.27.1)
If you remember, what version of Firefox/Gecko and Phoenix did you first notice the issue on?
2026.04.27.1
Does the issue occur on a new browser profile?
Please share your browser's distribution ID.
default
Please share your browser's update channel.
release
Please share a list of your currently installed browser add-ons/extensions, as well as the versions you have installed.
Phoenix defaults
Please explain the issue you are experiencing.
After
787b0a5d84, searching with duckduckgo.com / noai.duckduckgo.com from the urlbar, clicking on a result and navigating back to the search results page, shows the stock duckduckgo homepage (instead of the previously shown search results). This does not happen with any other shipped search engines that switched to POST, including duckduckgo html and lite, only on the full javascript duckduckgo search (default), and noai.Please provide detailed steps to reproduce the issue.
Backspaceon Windows,Alt+<-on *nix)Also, semi-related: first search (or after a while, when the PoW token expires) with disroot searx is always discarded, because their anubis PoW challenge on success doesn't redirect the POST request, so it just shows the searx homepage (you have to reenter the query into the searchbox, or search again from the urlbar).
Thank you!
Some other issues were reported on Matrix as well, so, I went ahead and switched the default engines back to
GETfor now - but I did add separatePOSTversions for each engine so that users can still use them if desired (for the added privacy/security).@celenity To prevent buggy behavior, it may be worth to just copy the expected search query format and method from the official opensearch plugins of the search engines:
https://duckduckgo.com/opensearch.xml // GET
https://noai.duckduckgo.com/opensearch.xml // GET
<method="get" template="https://duckduckgo.com/?q={searchTerms}"><method="get" template="https://noai.duckduckgo.com/?q={searchTerms}">https://duckduckgo.com/opensearch_lite.xml // POST
<method="post" template="https://lite.duckduckgo.com/lite/"><Param name="q" value="{searchTerms}"/>https://duckduckgo.com/opensearch_html.xml // POST
<method="post" template="https://html.duckduckgo.com/html/"><Param name="q" value="{searchTerms}"/>https://search.disroot.org/opensearch.xml // POST - although as said, the anubis check on that instance only breaks the first query; GET alt
<method="post" template="https://search.disroot.org/search"><Param name="q" value="{searchTerms}"/>https://www.mojeek.com/opensearch.xml // GET - page 2+ of search results switches to GET, even if the initial request was via POST anyways
<method="get" template="https://www.mojeek.com/search?q={searchTerms}">These also match how the frontend behaves, which prevents Phoenix users from standing out.
Startpage (both
wwwandeu) frontend makes queries via POST, while their opensearch plugin defines GET with a special url param (&pl=opensearch), which redirects to POST anyways (opensearch usage tracking?), so POST should be kept<method="post" template="https://www.startpage.com/sp/search"><Param name="query" value="{searchTerms}"/><method="post" template="https://eu.startpage.com/sp/search"><Param name="query" value="{searchTerms}"/>Also, it would be nice if
1a0516919ecould now be reverted and Marginalia re-added.@degausser Thank you for sharing these! Useful to have these for reference. Based on those configs, I went ahead and added the appropriate values for
Encoding(because I noticed we didn't have them set).Honestly, I think its still worth requiring our built-in search engines support POST, in order to hold them to the highest standards possible (and so we can ideally switch back to POST in the future if/when these issues are addressed).
I wonder why Marginalia doesn't currently support it? May reach out to them because eventually this will be a requirement for IronFox's search engines as well.
@celenity UTF-8 is the default encoding [1, 2].
@degausser wrote in #285 (comment):
Ah, I figured that was the case - still probably worth specifying explicitly though to ensure we avoid any issues in the future.