538607 - Add support for adding custom search plugins to a BYOB repack

Status: RESOLVED FIXED

(Websites Graveyard :: byob.mozilla.com, enhancement, P1)

Description

[Kev Needham [:kev]]

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.

Comment 1

[Les Orchard [:lorchard]]

Added time estimate to whiteboard.  Mostly straightforward, but seems to have a few tricky bits to watch for.

Comment 2

[Kev Needham [:kev]]

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

[Dan Mills [:thunder]]

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.

Comment 4

[Les Orchard [:lorchard]]

Bumping to P1, since I noticed this is mentioned in the Q1 goals

Comment 5

[Les Orchard [:lorchard]]

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?

[1]: https://developer.mozilla.org/en/Creating_OpenSearch_plugins_for_Firefox
[2]: https://developer.mozilla.org/en/Creating_MozSearch_plugins

Looks like it's MozSearch plugins in my Firefox profile, but not sure which it should accept.

Comment 6

[Les Orchard [:lorchard]]

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

[Kev Needham [:kev]]

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

[Kev Needham [:kev]]

...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.

Comment 9

[Les Orchard [:lorchard]]

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.

Comment 10

[Les Orchard [:lorchard]]

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:

http://dm-partdist-stage01.mozilla.org/

Comment 11

[Kev Needham [:kev]]

Thanks, Les! I think the image limitation is within Firefox itself, but I'll double-check.

Comment 12

[Les Orchard [:lorchard]]

I'm going to say this one's done, save for UI improvements and the http: icon issue in Firefox itself.

Comment 13

[Kev Needham [:kev]]

\o/ Concur.