Giters

nohamelin / xseei

A legacy Mozilla Firefox add-on to import and export search engines from XML files in the OpenSearch format

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Migrating to WebExtensions (if it will be possible) due to Firefox 57 dropping support for XUL-based add-ons

nohamelin opened this issue · comments

commented

Since Firefox 57, this so-called legacy add-on it's not possible to install. Only WebExtensions add-ons are supported by Fx.

The required personal work to do a full rewriting of the add-on to the WebExtensions model is not much of a issue per se, as the code-base is fairly "small", but, currently, it's not possible, as the necessary WE APIs in Firefox doesn't exist yet:

  1. A basic API requirement is to know enough data about each search engine to recreate it fully from a openSearch XML document object built from the former data. This is not possible at all: the Google Chrome API, used as base for WE, expose nothing about the engines. Besides the access to most attributes of the nsISearchEngine interface, many internal attributes are required too, making this requeriment very hard to see accomplished upstream. Bug 1352598 exposed a few properties, still far of the necessary.
    Check below for an available workaround.

  2. The importing of a openSearch XML file requires at least an API to create dynamically search engines. Again, it doesn't exist. Bug 1268401 was about it, closed by favoring engine enterprise policies, something (apparently?) not helpful for this case.

  3. All the UI integration with the Search pane of the Firefox Preferences pane will be lost, as, upstream, it's being considered only for system add-ons. So, I will need to move all the UI to a new html-based pane attached to a toolbar button, or a full in-content page: the usual UI choices left to WE add-ons. I'm hardly enthusiastic about this task.

  4. About filePickers:
    a) To allow the user to select one or more files to be imported, it's possible use the usual html element <input type="file"/>, though I will wait to bug 1292701 being fixed before playing with it.
    b) To allow the user to select the new file to be created at exporting, it looks that it's posible to trigger the "Save To" browser dialog with a blob object. I need to investigate it.

  5. To start to evaluate the exporting of the whole set of engines to a zip file, at least the previous points 1. and 4b. must be positively resolved. Besides that, I guess that it is possible: I didn't have investigated it yet.

commented

You might be interested: there's a discussion of switching to standard *.lz4 format. While it doesn't make porting easier, it may provide another way to solve the problem.

commented

It's worth keeping a eye to it, at least.

commented

A few alternatives to the classic Context Search add-on have started to implement the possibility to expand its own list of engines reading the search.json.mozlz4 file from the Fx profile. The approach is a bit awkward, as the file need be selected manually by the user (WebExtensions can't read arbitrary files from the profile), and it need be repeated each time that the set of Fx engines changes, but, well, at least it works. This approach can be used too to implement the exporting features of this add-on, the hardest requirement to be provided upstream.

The same could not be said for importing: it involves modifying that file, and whatever the extra technical issues with it are, I strongly suspect that it will not be accepted by AMO, as it goes against many "design ideas" about how WebExtensions are expected to interact with the browser, besides the fact that changes to the internal format of that file likely will break the add-ons relying on it, a long-standing problematic aspect with Fx extensions that Mozilla hopes to left in the past with the change to WebExtensions (and it's something that the linked add-ons already are pushing, and, in the worst case, AMO could end asking to remove that feature to the add-on authors).

commented

From Bug 1268401:

We have no plans to allow adding search engine dynamically via WebExtensions.
We've had too many problems with hijacking.

Specifying engines via manifest.json is the only way to add engines.

While it's possible to use a external website as an intermediary where your local search engine is uploaded and from where it's offered to the user to install (as the WebExtensions-based add-on Add custom search engine does), I'm not interested in developing using that approach.