Planned changes to iceweasel/iceape vs. freeze

[Mike Hommey]

On Thu, Aug 12, 2010 at 06:32:54AM +0100, Adam D. Barratt wrote:
> > - Possibly remove the libmozillainterfaces-java package. It is 
> >   apparently unused, not really maintained upstream (it's even being
> > removed from current trunk, in favor of a separate repository if a
> >   maintainer shows up), and more importantly, not tested.
> 
> My only concern with the removal is that people may be relying on it
> locally, although no packages in the archive depend on it.  Admittedly
> that's not a particularly overriding argument against shipping
> unmaintained code in stable.

There is also the concern that the xulrunner-1.9.1 package contains the
libjavaxpcomglue.so and javaxpcom.jar files that could be used by
something else, without using libmozillainterfaces-java, i.e. hidden
dependencies. I think the only package that could be relying on these is
eclipse, but that'd need to be checked.

> and the remainder:
> 
> > - Improve dh_xulrunner to also gather plugin information to, in the long
> >   term, help mimic Ubuntu's Xb-Npp-* control fields.
> 
> Forgive my ignorance here, but what are the fields in question used for?

In Ubuntu, they are used to gather information for the plugin finder
service. When firefox encounters a mime-type it doesn't know how to
handle in an <object> tag, it asks the plugin finder server what plugin
could work for that type. My (long term) idea for Debian is to not rely
on a server gathering the information, but on iceweasel checking in the
local package database for this information directly. I wanted to have
the helper before squeeze so that at least some packages could be filled
with that information. The plugin finder service using the packages info
could be provided as an external extension when it is ready.

> > - Add an option to dh_xulrunner to add the appropriate xulrunner package to
> >   something other than shlibs:Depends.
> 
> Are there specific use cases for this right now?

Probably not for stable, but who knows. I'm going to require that for
pyxpcom in experimental. I don't know if pyxpcom can build against
xulrunner-1.9.1, but if it does, I'm considering separating it out. But
that's still at the blurry idea stage.

> > - Improve or remove the restart popup that shows up when upgrading the
> >   package. The main problem it is trying to avoid is the impossibility
> >   to cleanly close iceweasel after an upgrade. I need to test further,
> >   but there are chances this is really only needed when upgrading
> >   between major versions
> 
> This would imply improving rather than removing, afaics.  (As removing
> it would presumably still leave the potential for things to go horribly
> wrong over a major version update?)

IIRC, there is a possibility for iceweasel to stay frozen on an empty
popup when you try to close the old version after you upgraded to the
new one. I need to check that before deciding if that will be improving
rather than removing.

> Finally, how large a change to the package do the following items imply?
> 
> > - Generate the iceweasel branding from upstream unofficial branding. I
> >   spotted a missing file in the current branding, so this would fix this
> >   and avoid it happening again in the future.

That would imply removing a good part of debian/branding and modifying
the Makefile or rules to have most of the branding copied over from
browser/branding/unofficial.

> > - Improve the situation with search box icons (those showing up in the
> >   box on the top right of the UI):
> >   the main problem is that the icons had to be removed from the source,
> >   because they are not free. The result is that now, the icons are
> >   really links to the icons on the original web sites. The problem is
> >   that the code surrounding this upstream is not adequate for such use,
> >   and the cache is not persistent enough, and a failure to load the icon
> >   once results in the icon never been reloaded ever again (except maybe
> >   after an upgrade)

Until I actually look at how this can be improved, I don't have an idea.
The good thing is that the cache doesn't need to be invented, because it
already exists. It only isn't persistent enough, and doesn't handle
offline on first load cases as mentionned above. I'd expect the patch to
be relatively small (especially compared to all the patches already
applied)

Cheers,

Mike