601899 - searchplugins are combined from all language packs

Status: RESOLVED WORKSFORME

(Firefox :: Search, defect)

Description

[Wolfgang Rosenauer [:wolfiR]]

With the latest changes in Firefox' chrome packaging I need to ship locales as full extensions. To avoid having one package per locale I need to install certain sets in parallel. Apparently that works more or less but now I get all searchplugins listed in the search dropdown and not only the ones from the currently active locale (and global ones).

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Dave, is that more a add-ons manager regression?

Comment 2

[Axel Hecht [:Pike]]

I'm not sure this is a regression in the first place. For Fennec's multi-locale build, we totally redid the packaging of searchplugins and their discovery, something we haven't ported to fx.

The initial report doesn't really say how that worked differently before, though.

Comment 3

[Wolfgang Rosenauer [:wolfiR]]

I don't know if it's a regression.
Since shipping locales as simple jars in the chrome directory is not possible with Firefox anymore I've been told to use full addons for multi locale support and so I tried.
Previously I had no localized searchplugins but only chrome dtds and properties.

Comment 4

[Dave Townsend [:mossop]]

(In reply to comment #1)
> Dave, is that more a add-ons manager regression?

Based on the information here I'd guess this is to do with us dropping support for contents.rdf (bug 492008) which landed for Firefox 3.6

(In reply to comment #0)
> With the latest changes in Firefox' chrome packaging I need to ship locales as
> full extensions. To avoid having one package per locale I need to install
> certain sets in parallel. Apparently that works more or less but now I get all
> searchplugins listed in the search dropdown and not only the ones from the
> currently active locale (and global ones).

Can you attach an xpi that demonstrates this behaviour?

Comment 5

[Axel Hecht [:Pike]]

Looking at comment 3, this is all "works as designed".

All installed language packs are active add-ons, and the searchplugins in them are all picked up.

The only way to actually get locale-dependent search plugins is to do something like fennec does, with prefs like

// Tell the search service to load search plugins from the locale JAR
pref("browser.search.loadFromJars", true);
pref("browser.search.jarURIs", "chrome://browser/locale/searchplugins/");

and to then do some custom packaging.

I'm all for WORKSFORME.

Comment 6

[Wolfgang Rosenauer [:wolfiR]]

This is getting annoying. Basically for every way I'm trying to solve the issue to have something like multi-locale builds for Firefox someone is telling me that it's not supported/wanted. Could someone please recognize that multi locale support is essential on the Linux desktop and you force every Linux distributor to use some hackish approach to achieve that?
I know this is not the right place for a general discussion but I needed to mention that.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

We're certainly not "forcing" you to use hackish approaches. You can always work with us to develop better-supported techniques of achieving what you want. That may be more work than just using a hack, granted, but that's a trade-off you're best suited to make. Given that you need to do something that no one else so far has really needed to do (support multi-locale firefox builds), it's somewhat inevitable that you're going to run into issues that you may need to sort out yourself.

As pike mentioned, the search service already supports loading locale-specific engines via chrome URIs (which was added because it was useful for multi-locale builds for Fennec) so you should be able to just use that functionality and adjust your packaging accordingly. Is there a reason that approach isn't suitable? I can help if you need guidance.

Comment 8

[Wolfgang Rosenauer [:wolfiR]]

Thanks Gavin

(In reply to comment #7)
> We're certainly not "forcing" you to use hackish approaches. You can always
> work with us to develop better-supported techniques of achieving what you want.

I said "forcing" because in the past my approach worked and changes in Firefox made that "feature" unavailable.
I know you don't want me to use hackish approaches but for several reasons it always ends up like that

> That may be more work than just using a hack, granted, but that's a trade-off
> you're best suited to make. Given that you need to do something that no one
> else so far has really needed to do (support multi-locale firefox builds), it's
> somewhat inevitable that you're going to run into issues that you may need to
> sort out yourself.

Noone else is certainly wrong. Most likely all Linux distributions have that issue. Fedora/Redhat is hacking around it by only linking used locales into Firefox' extension space during startup. That is for sure hackish.

What I criticize is the following: 
- the explained behaviour is clearly a bug to me. The fact that it doesn't 
  affect "normal" users of Firefox doesn't make it WORKSFORME as suggested.
  Is it really working as designed if someone uses multiple language packs to
  get all searchplugins displayed instead of the active locale?
- the fact that Mozilla is saying implicitely that this usecase/feature is
  not needed
- Mozilla behaving like it would be my problem. No, it's not. Noone expects
  me to do anything. I'm just a Linux user and happen to package Firefox for a 
  certain distribution as good as possible w/o getting sponsored or paid.

> As pike mentioned, the search service already supports loading locale-specific
> engines via chrome URIs (which was added because it was useful for multi-locale
> builds for Fennec) so you should be able to just use that functionality and
> adjust your packaging accordingly. Is there a reason that approach isn't
> suitable? I can help if you need guidance.

It might be suitable. I'm not sure how much work it is to implement it though.
I even might start working on that but a little bit of support from people knowing what to do would be nice.

Comment 9

[Dave Townsend [:mossop]]

(In reply to comment #8)
> Thanks Gavin
> 
> (In reply to comment #7)
> > We're certainly not "forcing" you to use hackish approaches. You can always
> > work with us to develop better-supported techniques of achieving what you want.
> 
> I said "forcing" because in the past my approach worked and changes in Firefox
> made that "feature" unavailable.

I'd be interested to see what the previous approach was that worked.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

When I said "you" above, I was referring generally to "Linux distributors". Your frustration seems to boil down to "multi-locale builds are not supported by the primary Firefox development team". You want multi-locale builds because you have packaging constraints that require them. Those constraints don't apply to Mozilla shipped builds. It sounds like you're upset that Mozilla as a community doesn't support your use case despite it only really being beneficial to you (again, using "you" in the general sense).

Work needs to be done to support that configuration. The only way to get underlying support for your use case is to a) convince other people to do work for you or b) do the work yourself or c) some combination of a) and b). a) alone might be hard :)

In this specific case, much of the work has already been done (because it was beneficial to Fennec). I'd be glad to help with any issues you encounter using the search service chrome URI loading code that already exists. I don't think this bug reflects anything actionable at this point, though, so I'm going to mark it WORKSFORME.

Comment 11

[Dave Townsend [:mossop]]

(In reply to comment #9)
> (In reply to comment #8)
> > Thanks Gavin
> > 
> > (In reply to comment #7)
> > > We're certainly not "forcing" you to use hackish approaches. You can always
> > > work with us to develop better-supported techniques of achieving what you want.
> > 
> > I said "forcing" because in the past my approach worked and changes in Firefox
> > made that "feature" unavailable.
> 
> I'd be interested to see what the previous approach was that worked.

Wolfgang followed up by email to explain that searchplugins have never worked before, he was mostly taking about the changes from bug 579178 which mean he can no longer drop manifest files into the chrome directory and expect them to work.