[BUG] Switch to POST queries on {noai.,}duckduckgo.com breaks browser backwards history navigation #285

degausser commented 2026年05月02日 12:29:19 +02:00

Confirmation Checklist

• I confirm that this issue occurs on the latest release of Phoenix. You can check what the latest version is on the Releases page.
• I confirm that this issue has NOT already been reported on the Codeberg issue tracker, the GitLab issue tracker, and/or the GitHub issue tracker.

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?

• Yes
• No

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.

1. search for anything with default 'DuckDuckGo', or 'DuckDuckGo (No AI)' search engines, from the urlbar
2. click on any result
3. navigate from the webpage back to the search results page (clicking the back arrow, or hitting Backspace on Windows, Alt+<- on *nix)
4. observe a stock DDG homepage, instead of the previously shown search results

### Confirmation Checklist - [x] I confirm that this issue occurs on the **latest release** of Phoenix. You can check what the latest version is on [the `Releases` page](https://codeberg.org/celenity/Phoenix/releases). - [x] I confirm that this issue has **NOT** already been reported on [the Codeberg issue tracker](https://codeberg.org/celenity/Phoenix/issues), [the GitLab issue tracker](https://gitlab.com/celenityy/Phoenix/-/issues), **and/or** [the GitHub issue tracker](https://github.com/celenityy/Phoenix/issues). ### 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? - [x] Yes - [ ] No ### 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 https://codeberg.org/celenity/Phoenix/commit/787b0a5d848dacce1b7e5497a10f96f65ea1dd56, 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. 1. search for anything with default 'DuckDuckGo', or 'DuckDuckGo (No AI)' search engines, from the urlbar 2. click on any result 3. navigate from the webpage back to the search results page (clicking the back arrow, or hitting `Backspace` on Windows, `Alt+<-` on *nix) 4. observe a stock DDG homepage, instead of the previously shown search results

degausser commented 2026年05月02日 12:51:47 +02:00

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).

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).

celenity commented 2026年05月07日 04:52:06 +02:00

Thank you!

Some other issues were reported on Matrix as well, so, I went ahead and switched the default engines back to GET for now - but I did add separate POST versions for each engine so that users can still use them if desired (for the added privacy/security).

Thank you! Some other issues were reported on Matrix as well, so, I went ahead and switched the default engines back to `GET` for now - but I did add separate `POST` versions for each engine so that users can still use them if desired *(for the added privacy/security)*.

degausser commented 2026年05月07日 13:52:53 +02:00

@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 www and eu) 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 1a0516919e could now be reverted and Marginalia re-added.

@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](https://search.disroot.org/opensearch.xml?method=GET) `<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 `www` and `eu`) frontend makes queries via POST, while their [opensearch plugin](https://cdn.startpage.com/sp/cdn/opensearch/en/opensearch.xml) 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 https://codeberg.org/celenity/Phoenix/commit/1a0516919e3fcd2e196648b794b7aa0088e4aa14 could now be reverted and Marginalia re-added.

celenity commented 2026年05月07日 20:59:48 +02:00

@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).

Also, it would be nice if 1a0516919e could now be reverted and Marginalia re-added.

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.

@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)*. > Also, it would be nice if [`1a0516919e`](https://codeberg.org/celenity/Phoenix/commit/1a0516919e3fcd2e196648b794b7aa0088e4aa14) could now be reverted and Marginalia re-added. 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.

degausser commented 2026年05月07日 22:25:58 +02:00

@celenity UTF-8 is the default encoding [1, 2].

@celenity UTF-8 is the default encoding [[1](https://mozilla.github.io/policy-templates/#searchengines--add:~:text=defaults%20to%20UTF%2D8), [2](https://github.com/dewitt/opensearch/blob/master/opensearch-1-1-draft-6.md#the-inputencoding-element:~:text=Default%3A%20%22UTF%2D8)].

celenity commented 2026年05月08日 05:30:25 +02:00

@degausser wrote in #285 (comment):

@celenity UTF-8 is the default encoding [1, 2].

Ah, I figured that was the case - still probably worth specifying explicitly though to ensure we avoid any issues in the future.

@degausser wrote in https://codeberg.org/celenity/Phoenix/issues/285#issuecomment-14467910: > @celenity UTF-8 is the default encoding [[1](https://mozilla.github.io/policy-templates/#searchengines--add:~:text=defaults%20to%20UTF%2D8), [2](https://github.com/dewitt/opensearch/blob/master/opensearch-1-1-draft-6.md#the-inputencoding-element:~:text=Default%3A%20%22UTF%2D8)]. Ah, I figured that was the case - still probably worth specifying explicitly though to ensure we avoid any issues in the future.