I uploaded some extensions to the add-on dev hub as normal. I'll just discuss one example for simplicity's sake.
This extension's manifest is very similar to Firefox's built-in search extensions, because my intention was to replace the built-in engines with my own engines where I can control the icon. Some of the built-in engines are fine and have x-suggestions URLs (like Amazon) though others lack suggestions when an API is actually available. I've been meaning to file a bug about this on Firefox but it slipped my mind since I don't know what component to file it under.
I also wanted to replace the icons so they look consistent with built-in icons. That is, replace colorful ICO images with SVG files with context properties, so the icon can respond to themes.
Anyway, here is the form of my version of the Amazon extension. As you can see it's nearly identical to the built-in extension.
{
"name": "Amazon (Search)",
"description": "__MSG_extensionDescription__",
"manifest_version": 2,
"version": "1.3",
"applications": {
"gecko": {
"id": "amazondotcom@aminomancer"
}
},
"hidden": true,
"default_locale": "en",
"icons": {
"16": "favicon.svg"
},
"web_accessible_resources": ["favicon.svg"],
"chrome_settings_overrides": {
"search_provider": {
"keyword": "@ama",
"name": "Amazon",
"search_url": "__MSG_searchUrl__",
"search_form": "__MSG_searchForm__",
"suggest_url": "__MSG_suggestUrl__",
"search_url_get_params": "__MSG_searchUrlGetParams__"
}
}
}
And here are some of those localized messages:
{
"extensionName": {
"message": "Amazon.com"
},
"extensionDescription": {
"message": "Amazon.com Search"
},
"searchUrl": {
"message": "https://www.amazon.com/exec/obidos/external-search/"
},
"searchForm": {
"message": "https://www.amazon.com/exec/obidos/external-search/?field-keywords={searchTerms}&ie={inputEncoding}&mode=blended&tag=mozilla-20&sourceid=Mozilla-search"
},
"suggestUrl": {
"message": "https://completion.amazon.com/search/complete?q={searchTerms}&search-alias=aps&mkt=1"
},
"searchUrlGetParams": {
"message": "field-keywords={searchTerms}&ie={inputEncoding}&mode=blended&tag=mozilla-20&sourceid=Mozilla-search"
}
}
Again, you can see how they match the built-in extension's messages.
And here are my results after uploading to AMO developer hub:
"/chrome_settings_overrides/search_provider/search_url" should match pattern "^(https://|http://(localhost|127\.0\.0\.1|\[::1\])(:\d*)?(/|$)).*$"
"/chrome_settings_overrides/search_provider/search_url" should match format "url"
"/chrome_settings_overrides/search_provider/suggest_url" should match pattern "^$|^(https://|http://(localhost|127\.0\.0\.1|\[::1\])(:\d*)?(/|$)).*$"
"/chrome_settings_overrides/search_provider/search_form" should match pattern "^(https://|http://(localhost|127\.0\.0\.1|\[::1\])(:\d*)?(/|$)).*$"
"/chrome_settings_overrides/search_provider/search_form" should match format "url"
Please correct me if I'm mistaken and this is just an issue with my syntax. But I have used the same syntax before with no problems, and for most of these search engines I just copied the l10n files from Firefox's source code. It seems to only become a problem when I try to define a search parameter with a l10n message.
It seems like the linter isn't capable of interpreting the localization syntax and finding message values? Idk. Anyway, I made 4 of these search extensions. I don't really need the extensions to be signed, it's not a big deal. But it would be nice to not have to tell my users to disable the signing requirement, and put up with the alarming "unverified" message in about:addons.
Of course one way or another, if they're using my search extensions, they're already messing with their Firefox profile or installation pretty heavily. But I think this might be a bigger issue beyond just my applications, because shouldn't there be lots of search extensions with localized search parameters? If I want to provide search suggestions in the user's language, declaring one suggest_url is not sufficient. I can't think of any way to deliver localized suggestions without this feature, since it's not like there's any infrastructure set up for dispatching or receiving l10n information with the initial request. (to my knowledge)
Thanks 🙏
┆Issue is synchronized with this Jira Task
I uploaded some extensions to the add-on dev hub as normal. I'll just discuss one example for simplicity's sake.
This extension's manifest is very similar to Firefox's built-in search extensions, because my intention was to replace the built-in engines with my own engines where I can control the icon. Some of the built-in engines are fine and have x-suggestions URLs (like Amazon) though others lack suggestions when an API is actually available. I've been meaning to file a bug about this on Firefox but it slipped my mind since I don't know what component to file it under.
I also wanted to replace the icons so they look consistent with built-in icons. That is, replace colorful ICO images with SVG files with context properties, so the icon can respond to themes.
Anyway, here is the form of my version of the Amazon extension. As you can see it's nearly identical to the built-in extension.
And here are some of those localized messages:
Again, you can see how they match the built-in extension's messages.
And here are my results after uploading to AMO developer hub:
Please correct me if I'm mistaken and this is just an issue with my syntax. But I have used the same syntax before with no problems, and for most of these search engines I just copied the l10n files from Firefox's source code. It seems to only become a problem when I try to define a search parameter with a l10n message.
It seems like the linter isn't capable of interpreting the localization syntax and finding message values? Idk. Anyway, I made 4 of these search extensions. I don't really need the extensions to be signed, it's not a big deal. But it would be nice to not have to tell my users to disable the signing requirement, and put up with the alarming "unverified" message in about:addons.
Of course one way or another, if they're using my search extensions, they're already messing with their Firefox profile or installation pretty heavily. But I think this might be a bigger issue beyond just my applications, because shouldn't there be lots of search extensions with localized search parameters? If I want to provide search suggestions in the user's language, declaring one
suggest_urlis not sufficient. I can't think of any way to deliver localized suggestions without this feature, since it's not like there's any infrastructure set up for dispatching or receiving l10n information with the initial request. (to my knowledge)Thanks 🙏
┆Issue is synchronized with this Jira Task