Currently we store our OpenSearch providers to disk in ~/.local/share/org.sailfishos/browser/searchEngines/ in their original XML file format. For example:
$ ls -1
duckduckgo.com.xml
forum.sailfishos.org.xml
github.com.xml
www.openstreetmap.org.xml
These then get loaded in at start up by making repeated calls to SearcService.addOpenSearchEngine() in EmbedLiteSearchEngine.js.
Firefox does it differently: it loads the XML from the Web but stores the details out to ~/.local/share/org.sailfishos/browser/.mozilla/search.json.mozlz4 in compressed JSON format, which it then loads back in at start up.
Because of this, in ESR 91 gecko no longer supports loading in the XML files from disk. It's easy for us to patch around this, but it would be nicer to just support the SearchSettings approach of loading the providers in from the compressed JSON file at start up, especially given that this file is already being saved out to disk (so we're currently storing the info twice).
Currently we store our OpenSearch providers to disk in
~/.local/share/org.sailfishos/browser/searchEngines/
in their original XML file format. For example:These then get loaded in at start up by making repeated calls to
SearcService.addOpenSearchEngine()
inEmbedLiteSearchEngine.js
.Firefox does it differently: it loads the XML from the Web but stores the details out to
~/.local/share/org.sailfishos/browser/.mozilla/search.json.mozlz4
in compressed JSON format, which it then loads back in at start up.Because of this, in ESR 91 gecko no longer supports loading in the XML files from disk. It's easy for us to patch around this, but it would be nicer to just support the SearchSettings approach of loading the providers in from the compressed JSON file at start up, especially given that this file is already being saved out to disk (so we're currently storing the info twice).