Add support for adding custom search plugins to a BYOB repack



Websites Graveyard
9 years ago
4 years ago


(Reporter: kev, Unassigned)



(Whiteboard: 12 hrs)



9 years ago
Currently there is no way to specify additional search plugins to be included with a customized distribution of Firefox created with BYOB. This bug is a request for enhancement to permit a repack creator with the ability to upload up to three additional search plugins for (a) provider(s) that are not supplied by default to a given BYOB repack. This function would be added to the configuration dialogue/wizard, and would have the following requirements:

- ability to upload the search plugin xml through the configuration application
- check plugin syntax for validity
- verify plugin does not have an update url defined
- verify the plugin does not conflict with existing Firefox defaults
- extract XML metadata (shortname, longname, and search URL + params) for disply in the browser config/summary/admin review information
- on repack generation, copy the plugin to the distribution/searchplugins/common directory

Optionally (and ideally) we'd provide the additional functionality:

- add the ability to specify locale-specific versions of a plugin, and which locale should be used as a default
- on repack generation, copy the plugins to the appropriate distribution/searchplugins/locale/{locale} directory, and set the "distribution.searchplugins.defaultLocale" pref in the "Preferences" section to the specified default locale

No reordering or modification/overwrites of existing search plugins will be permitted. The additional plugins will be sorted alphabetically.
Added time estimate to whiteboard.  Mostly straightforward, but seems to have a few tricky bits to watch for.
Priority: -- → P2
Whiteboard: 12 hrs

Comment 2

9 years ago
The trickiest bit is that the default locale will only be read if a locale directory does not exist. e.g. if you put 3 plug-ins in en-US, and set it as default, and 1 plug-in in de, the de localization will only take up the 1 plug-in. we either need to make that very clear in the wizard, or figure out a way to ensure that plug-ins are backfilled automagically. alternatively, we can just force the use of common for now, as it probably won't affect a significant number of distros.

it may be also worth the investment to see if we can modify nsBrowserDirectoryProvider.cpp so that it'll use what's in common as a global and trump/append based on what's included in locales. 

cc'ing thunder for comment.

Comment 3

9 years ago
I would not recommend using plugins from the default if there is a locale directory.  Doing so would not allow you to remove a default plugin in one locale.

However, BYOB could automatically populate the default plugins when a locale override is created, or provide a single-click "import default plugins" type option.

The downside for the flexibility of having locale overrides like this is that plugin versions would need to be kept up to date in multiple versions.  I think however that this problem could be mitigated in BYOB, by offering to update all copies of a plugin (in all locales) when you upload a new version.
Bumping to P1, since I noticed this is mentioned in the Q1 goals
Priority: P2 → P1
Working my way through building a parser / validator for search plugins, and got a question:  Are we expecting OpenSearch [1] plugins here, or MozSearch [2] plugins?


Looks like it's MozSearch plugins in my Firefox profile, but not sure which it should accept.
It looks like the MozSearch is meant to be internal only, but... should I be doing something like accepting an OpenSearch but writing a MozSearch format to the repack directory? (Which sounds potentially messy)

Comment 7

9 years ago
What we should do is assume the search plugin file is in a proper format, and allow the user to upload it, and copy it in place as-is. We can do some XML syntax checking, but I don't know how involved we want it to be. Do we do any upload checking on AMO? There will be an editor checking things out, as well.

Comment 8

9 years ago
...essentially I want to make the assumption that what the author uploads will meet criteria. If it doesn't, Firefox will throw an exception and ignore it. I don't know if there's a parser we can reuse for it, but I agree any kind of transformation can be messy and, as such, should be avoided.
So, I'm making progress...

It looks like <OpenSearchDescription> documents work in the distribution directory, with one hitch:  If the search plugin has http: URLs for <Image> icons, Firefox doesn't display them.  They need to be converted to data: URLs with the image source data embedded.
Just checked in r64114 with an initial implementation of the search plugin upload feature.  It could probably use some UI enhancements, and the icons don't work unless they're supplied as data: URLs, but beyond that it should start working on staging:

Comment 11

9 years ago
Thanks, Les! I think the image limitation is within Firefox itself, but I'll double-check.
I'm going to say this one's done, save for UI improvements and the http: icon issue in Firefox itself.
Last Resolved: 9 years ago
Resolution: --- → FIXED

Comment 13

9 years ago
\o/ Concur.


4 years ago
Product: Websites → Websites Graveyard
You need to log in before you can comment on or make changes to this bug.