Preserve cookies after query

[israelyago]

What does this PR do?

Implements the "preserve preferences URL parameter as cookies" #2958

Why is this change important?

After making a search with the url preferences, the user expects it's settings to persist across more searches. The current behavior does not persist the user configuration.

This branch allows the user to have it's, e.g. dark mode ON even after the first query

How to test this PR locally?

1. Set your theme to dark mode
2. Go to the /preferences page
3. Copy the preferences URL
4. Open an anonymous browser tab
5. Paste the preferences URL and update the last q=%s to q=dog

At the search results page, confirm that you are in dark mode
Go to the images page, confirm that you still have the dark mode

Related issues

#2958
https://gitlab.e.foundation/e/backlog/-/issues/1154

[kvch]

I have slept on the original issue. My main concern, cookies being accidentally overwritten, is still there. However, as a compromise we could merge this functionality. But we should add a new checkbox to the preferences URL, maybe called "save to cookies", and pass it through with the preferences string as is. Example http://localhost:8888/?preferences={string}&save=true and this would instruct searx to save the preferences to cookie. If save is set to false, it would behave as before, not save the preferences. By default, it should be set to false, so we are not breaking the expected behaviour. WDYT?

[israelyago]

I have slept on the original issue. My main concern, cookies being accidentally overwritten, is still there. However, as a compromise we could merge this functionality. But we should add a new checkbox to the preferences URL, maybe called "save to cookies", and pass it through with the preferences string as is. Example http://localhost:8888/?preferences={string}&save=true and this would instruct searx to save the preferences to cookie. If save is set to false, it would behave as before, not save the preferences. By default, it should be set to false, so we are not breaking the expected behaviour. WDYT?

That seems good to me; I will come back with the new updates

[israelyago]

@kvch I thought the requested changes would be pretty simple to make, but I was surprised with the way the system works.
Our toggles send the inverted value to the server and somehow it works.

This search engine, which is DISABLED and have a UI id of "engine_archive_is__general" have a internal value of checked as "true":

And when submitting the form:

Is this the expected and right behavior of the system?

[kvch]

Yes, unfortunately, this is the expected behaviour. It was implemented a long time ago, probably one of the first features of searx. We never changed it because we were afraid to break existing user preferences preserved in cookies.

[kvch]

I have tested the PR and the functionality works. But the display if the preferences are supposed to be saved stays grey on reload.

[israelyago]

... But the display if the preferences are supposed to be saved stays grey on reload.

Yes, that's how I found out the little problem we have in the preferences thing; I'm still unsure how to fix the "Not updating the toggle" on reload