Closed Bug 1677796 Opened 4 years ago Closed 4 years ago

Consider saving enabled/disabled search engines in Firefox/Thunderbird via prefs

Categories

(Firefox :: Search, enhancement)

78 Branch
enhancement

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jmkrnet, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

I wanted to make a backup of relevant Firefox/Thunderbird configs from their profile folder in a way that eliminates files that are changed by the application on every usage. The "search.json.mozlz4" file is one of the few files that are preventing me from achieving that goal.

Actual results:

Currently the enabled/disabled state for each search engine in Firefox/Thunderbird is saved in "search.json.mozlz4" file, which is not very suitable for config backup purposes. That is because Firefox/Thunderbird updates the file during each session (or at least very often) and one cannot easily see changes in the file since it is not a normal JSON file viewable in a text editor.

Expected results:

Thus, I propose saving enabled/disabled state of search engines in a pref that can be used in "prefs.js" or "user.js" files. This will allow simple profile backups to skip the "search.json.mozlz4" file.

Of course if users need to customize the search engines in any way besides enable/disable they will still need to mess around with the "search.json.mozlz4" file. So the main "evil" side effect of the "search.json.mozlz4" file (i.e. to prevent most users from customizing search engines in detail) will remain intact:). Jokes aside, the proposed change should not require any changes in the file. Only the enable/disable status of search engines will need to be synchronized to reflect the value from the proposed pref. Or implementation can remove the enable/disable status of search engines from the "search.json.mozlz4" file and store it in the proposed pref only.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Search

(In reply to Bakhelit from comment #0)

That is because Firefox/Thunderbird updates the file during each session (or at least very often) and one cannot easily see changes in the file since it is not a normal JSON file viewable in a text editor.

We are working on reducing that. Although it gets touched every startup at the moment (bug 1596398), the content shouldn't generally be changing - only version updates would be the unnecessary content change at the moment where we bump the buildID (which we probably don't need to do now).

Thus, I propose saving enabled/disabled state of search engines in a pref that can be used in "prefs.js" or "user.js" files. This will allow simple profile backups to skip the "search.json.mozlz4" file.

If a user is backing up the profile, I would highly recommend backing up every file in the profile. Skipping files, or only backing up selectively is likely to loose data if Firefox adds more files later on.

Of course if users need to customize the search engines in any way besides enable/disable they will still need to mess around with the "search.json.mozlz4" file.

This is not something that we support directly. We are working on adding functionality for custom engines which will give users what they need to from the UI.

Therefore, I think with the changes to saving the file, and with the future custom engine changes, I think your needs would be satisfied?

Flags: needinfo?(Bakhelit)

Thank you for all the info. I looked at bug 1596398 and added it to my follow list, since it would certainly help me nicely if proposed changes are implemented.

UI for custom search engines or a search engines customization could be also nice. Although since I recently switched away from Google I noticed I can live quite nicely with the default DuckDuckGo search engine provided by Firefox/Thunderbird. The DuckDuckGo !Bang functionality really replaces any need for multiple search engines, at least for me:).

If the future custom engine UI will store its settings (at least enabled/disabled search engines) in some file (idealy readable in text editor:) that is changed only when requested by the user, then it would solve all my problems. Same would be true if the UI would instead offer users the possibility to export search engines settings. This could be simillar to how I handle bookmarks: I do not care about the "places.sqlite" file or "bookmarksbackups/*.jsonlz4" files, but instead I just use exported bookmarks in a normal JSON file that Firefox generates when requested by the user from UI.

Regarding my backup strategy (although it is only relevant as a related background info):
Doing a Firefox/Thunderbird profile backup only for selected files has worked for me so far. It may be more work initially to decide which files one needs, but it prevents all kinds of problems associated with bloated old profiles full of useless old files accumulated over the years. A lot of the files contain a cache-like data anyway and Firefox/Thunderbird is able to regenerate them again if these files are missing, so you can have mostly fresh profile all the time just with the data you need:).

In general only problems arrise when one needs to backup settings from a file that contains frequently changed cache-like data mixed together with user settings. But if all applications would distinguish more strictly between user settings and application generated cache-like data world would be perhaps too perfect:D.

Flags: needinfo?(Bakhelit)

Thank you for the response.

I don't see any strong use cases for changing the file format here, editing the settings files directly are never something we've said we'll support, and we do encode it for various reasons. Hence, we're not planning on changing this at this time, an so I'll mark this as wontfix.

Of course, hopefully we'll soon get to bug 1596398 and so we'll be writing to it less overall which will help the other part of this for you.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.