Omnibox in a non-english Tor Browser has no Disconnect.me as search engine in 6.0a5
We lost Disconnect.me as search engine somehow in our non-en-US bundles. Seems legacy/trac#11236 (moved) is showing its ugly head again (see comment 9 and https://bugzilla.mozilla.org/show_bug.cgi?id=1126722). Sad that our test suite is broken by the transition to ESR45 as well otherwise we would have caught this one earlier (too) :/
Activity
added GeorgKoppen201605 in Legacy / Trac TorBrowserTeam201605R in Legacy / Trac component::applications/tor browser in Legacy / Trac ff45-esr in Legacy / Trac owner::gk in Legacy / Trac priority::very high in Legacy / Trac resolution::fixed in Legacy / Trac severity::critical in Legacy / Trac status::closed in Legacy / Trac type::defect in Legacy / Trac labels
I noticed that in our "Omnibox patch" we add various *.xml files (search engine definitions) to the directory
browser/locales/en-US/searchplugins/. So it would seem that this patch is specifically adding search engines for the US English locale only. I'm not sure why this approach would have provided the correct search engines in non-English in TBB/ESR38, but it at least seems like a plausible explanation for the problem we see in TBB/ESR45.There's another directory,
browser/locales/generic/, that at least superficially looks like it may provide its contents to every locale. So I added a matchingsearchpluginsdirectory and added disconnect.xml and youtube.xml therein. I'm currently building the full tor-browser-bundle.git with this change, and I'll report the results soon.
Thanks to fqueze for debugging help! It seems that https://bugzilla.mozilla.org/show_bug.cgi?id=1162569 is the likely culprit.
We have a bunch of options here
- We override
re[/search-plugins/](/search-plugins/`) to point to a custom location - We ship our search plugins in a distribution folder
- We replace the lang pack search engines and list.txt with the ones we want to get used during the bundling step.
I think I prefer 3) for at least two reasons: a) We can be sure that only our plugins get shipped. No other code path can use search plugins we don't want to get used. b) we avoid another possible Tor Browser patch.
- We override
-
bug_18915_v2 (https://gitweb.torproject.org/user/gk/tor-browser-bundle.git/commit/?h=bug_18915_v2&id=9ec08e87c4ce181fa79f8d5355a471ba8939788e) is up for review. I tested this with a hardened-nightly and on all platforms we support by rebundling an alpha.
Adding anonym, as I don't know how Tails is doing the localization and whether they are using the lang packs we ship or not.
Trac:
Cc: mcs, brade, arthuredelstein to mcs, brade, arthuredelstein, anonym
Keywords: TorBrowserTeam201605 deleted, TorBrowserTeam201605R added
Status: assigned to needs_review 
Replying to gk:
Adding anonym, as I don't know how Tails is doing the localization and whether they are using the lang packs we ship or not.
Thanks for thinking about us! :)
In Tails we do localization essentially like this:
-
We install all your langpacks in the extensions directory, then Tor Browser picks the right one according to the
LANGenv var. Furthermore, it will pick localized search plugins fromdistribution/searchplugins/locale/$LANGCODE/(used below). -
We dynamically generate localized search plugins for Disconnect, Startpage and Wikipedia, replacing your variants of these. Since we provide the English Wikipedia plugin for all locales, we generate localized icons (using imagemagick) for Wikipedia, by putting the lang code in the bottom-right corner.
-
We also install all search plugins from Debian's
ìceweasel-l10n-*for which we have langpacks. (Personally I'd happily drop these since they mainly seem to add commercial crap.)
So, we are not affected by this bug since we generate our own thing. However, I worked on integrating 6.0a5 into Tails yesterday and noticed a related issue (for us), namely that you now put your search engine plugins inside
distribution/omni.ja, which makes it harder for us to replace them. I guess the best, touch, would be if we settled on the same search plugins, and we did nothing regarding this on Tails' side. I also realize that this is not the right ticket for this -- if you think there's an interest in harmonizing this I can open a new ticket.-
-
Replying to anonym:
Replying to gk:
Adding anonym, as I don't know how Tails is doing the localization and whether they are using the lang packs we ship or not.
Thanks for thinking about us! :)
In Tails we do localization essentially like this:
- We install all your langpacks in the extensions directory, then Tor Browser picks the right one according to the
LANGenv var. Furthermore, it will pick localized search plugins fromdistribution/searchplugins/locale/$LANGCODE/(used below).
Okay, you should be fine then I think.
-
We dynamically generate localized search plugins for Disconnect, Startpage and Wikipedia, replacing your variants of these. Since we provide the English Wikipedia plugin for all locales, we generate localized icons (using imagemagick) for Wikipedia, by putting the lang code in the bottom-right corner.
-
We also install all search plugins from Debian's
ìceweasel-l10n-*for which we have langpacks. (Personally I'd happily drop these since they mainly seem to add commercial crap.)
So, we are not affected by this bug since we generate our own thing. However, I worked on integrating 6.0a5 into Tails yesterday and noticed a related issue (for us), namely that you now put your search engine plugins inside
distribution/omni.ja, which makes it harder for us to replace them. I guess the best, touch, would be if we settled on the same search plugins, and we did nothing regarding this on Tails' side. I also realize that this is not the right ticket for this -- if you think there's an interest in harmonizing this I can open a new ticket.If that helps you then let's look at it. However, I am not sure I understand you. We actually did not change anything with our switch from ESR38 to ESR45 which is why we have this bug :). Specifically, we don't put our search engines into
distribution/omni.ja. If I extract e.g. the Linux 32bit en-US bundle, the only omni.ja files I get areBrowser/omni.ja,Browser/browser/omni.jaandBrowser/webapprt/omni.ja. The search engines are still in the second one. - We install all your langpacks in the extensions directory, then Tor Browser picks the right one according to the
Kathy and I reviewed these changes (although we did not run a bundling step with them). The changes look fine except we think that the chrome directory should be cleaned up after extracting the search plugin files from omni.ja (as is done for defaults), e.g., after:
mv chrome/en-US/locale/browser/searchplugins ~/buildadd:rm -rf chromeTrac:
Status: needs_review to needs_revisionmentioned in issue legacy/trac#18954 (moved)
mentioned in issue legacy/trac#19065 (moved)
mentioned in issue legacy/trac#19176 (moved)
mentioned in issue legacy/trac#20680 (moved)
mentioned in issue legacy/trac#21309 (moved)
mentioned in issue legacy/trac#21851 (moved)
mentioned in issue legacy/trac#27466 (moved)