[Pkg-mozext-maintainers] Bug#571596: Iceweasel do not start after removal of xul-ext-torbutton
lunar at debian.org
Fri Oct 8 09:32:04 UTC 2010
On Fri, Oct 08, 2010 at 10:23:19AM +0200, Mike Hommey wrote:
> So, I was able to reproduce the issue, and the blame is shared between both
> iceweasel and torbutton. The problem here is that torbutton overrides
> one of the core components of iceweasel (exthandler), and as such
> iceweasel uses torbutton's. After torbutton removal, iceweasel fails to
> initialize the exthandler component because it disappeared, and thus
> can't start.
> I think this is a core problem in iceweasel/gecko (which also applies to
> other gecko-based applications), and I think the best we can do in a
> timely manner, without waiting for an absolute right fix is to use
> dpkg triggers.
> The way it would work is that dangerous extensions such as torbutton
> would send a trigger to iceweasel and other packages it would break
> (icedove, iceape...), which name we'd agree upon (how about
> xulrunner-autoreg?) and iceweasel and other packages would do the right
I might not be knowledgeable enough to have a clear idea of what such
trigger will do. Would you be kind enough to give more details on what
Are you aware of any other extensions that would benefit from such
I just had a quick look at every packages containing an install.rdf
file, and I have not spotted anything looking like core components
overidden by other extensions. I have also done quick tests for
foxyproxy, iceweasel-downthemall, iceweasel-vimperator,
mozilla-imagezoom, mozilla-livehttpheaders, xul-ext-greasemonkey and
xul-ext-webdeveloper. None exhibits the same behaviour as torbutton.
Jérémy Bobbio .''`.
jeremy.bobbio at irq7.fr : : : lunar at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 835 bytes
Desc: Digital signature
More information about the Pkg-mozext-maintainers