Bug#742531: keyword.URL preference ignored after upgrade to version 23+
hagfish at hagfish.name
Tue Mar 25 18:23:05 UTC 2014
Thank you for your clear explanation. Hopefully I can explain my
position better this time.
>> As I see it, this is just a case of a config file format change, and
>> typically a Debian package would try to help the user preserve any
>> user-set value after upgrade. Also, as in the example I gave, this
>> unannounced change of behaviour could lead to someone leaking sensitive
>> search terms out to an unintended third party, which has
>> privacy/security implications.
> Well, I haven't looked into the source code but if the preference has
> been removed from
> the configuration, I don't think the feature is still available.
> Having Debian taking care of bringing back features removed by upstream
> is a huge work.
Absolutely, and I wouldn't expect Debian to independently write and
maintain an extra configuration option which upstream didn't want.
In my original bug report I gave the steps for a manual workaround to
this problem, but perhaps I should have made explicit that I see this
workaround as evidence that the preference still exists, just in a
different form. Mozilla have, quite wisely, decided that it doesn't
make sense for most people to have two different default search engines
(one for searches in the address bar and one for searches from the
search widget), so they now use the search widget preference for both.
What I'm saying is, if a user has gone to the trouble of setting a value
for keyword.URL then this value should be used to set the default search
engine after the upgrade.
>> This issue seems similar to:
> I don't see that as a packaging bug. I don't think it is the goal of
> Debian to manage that.
As a precedent for Debian creating packages which automatically deal
with configuration format changes (which I hope you'll agree based on
the above is the situation here), please consider this documentation of
the apache2 package:
> If you think it should be managed, you should push the change upstream
> (or look if there is an extension
> doing it):
As you're probably aware, Mozilla are somewhat hesitant at applying
platform- (and certainly distro-) specific changes, for example:
and I imagine that the handling of the config files related to this bug
is tightly bound to iceweasel/Debian. Also I think it is unreasonable
to expect a user to wait until the upgrade has trampled their settings,
and sent their private data to a third party, before they go and search
for an extension which takes more effort to install than just fixing the
> Otherwise, expect if you provide a patch and commit to maintain it, yeh,
> I will probably close
> it like #720968
Well it seems to me that one benefit of having bugs open in a bug
tracker is so that people can be kept aware of what issues affect the
software they use, and potentially step forward to fix them if they have
the skill or resources to do so. Closing a wishlist bug because a
volunteer hasn't yet been found seems counterproductive from that point
of view. In any case, this bug only affects the wheezy -> jessie stable
transition, so feel free to close this after wheezy EOL.
More information about the pkg-mozilla-maintainers