293017 - implement em:requires

Status: RESOLVED DUPLICATE of bug 298497

(Toolkit :: Add-ons Manager, enhancement)

Description

[Przemyslaw Bialik]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

Some background:
http://www.bengoodger.com/software/mb/extensions/packaging/extensions.html
"em:requires
    A object specifying another extension that is required by this extension.
em:id specifies the GUID of the extension that is required, em:minVersion
specifies the minimum required version and em:maxVersion - much as for
em:targetApplication. An Extension's manifest can specify 0 or more of these
em:requires objects.
Note: This field does not do anything in Firefox 0.9 but will in the future be
used to disable chains of incompatible extensions. Please begin using it now."

Time passed and this field is still skipped by the EM and some authors are
making use of it for their extensions and some not probably because currently it
is useless.

Some examples of extensions that require http://jslib.mozdev.org/ to work:
Mozcc_0.9.3.xpi, ThunderFilter_0.2.xpi, citations_0.2.1.xpi, TagZilla_0.059.xpi.
Other requirements:
- ProfilePasswordButton_0.1.xpi requires ProfilePassword
- Calendar_Help_0.5.xpi requires Mozilla Calendar
All available from http://www.extensionsmirror.nl/ .

Reproducible: Always

Steps to Reproduce:
1. Install e.g. Calendar_Help_0.5.xpi on profile which does not have Mozilla
Calendar installed

Actual Results:  
It installs.

Expected Results:  
- It should not install because of having:
<em:requires>
      <!-- Calendar -->
      <Description
        em:id="{8e117890-a33f-424b-a2ea-deb272731365}"
        em:minVersion="0.7"
        em:maxVersion="0.9" />
    </em:requires>
in install.rdf.
- Show a message that "Calendar Help 0.5 cannot be installed because Mozilla
Calendar (from em:name) extension is not installed."
And other messages if the required extension is installed but with different
version (similar when <em:targetApplication> does not match).

Comment 1

[Przemyslaw Bialik]

Attachment: Calendar_Help_0.5.xpi

Comment 2

[Przemyslaw Bialik]

Attachment: TagZilla_0.059.xpi

After installation of TagZilla (without having jslib installed) Firefox browser
does not open (even on trunk Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.8b2) Gecko/20050503 Firefox/1.0+)

Comment 3

[Nickolay_Ponomarev]

confirming (btw, you don't have to attach 250KB of XPIs.)

Comment 4

[Przemyslaw Bialik]

Thanks (250KB for 2 xpi's is not that much, Piggy-Bank_1.0.0.xpi takes over 8MB
- not that I was planning to attach it ;) , but yeah attaching
Calendar_Help_0.5.xpi was probably too much for the convenience of others).

Severity - only enhancement ?
Users have problems (even major) when they forget or did not read that they had
to install dependent extension.
Should the installing e.g. tagzilla without jslib be another bug ? - It
currently does not make use of em:requires and others might also not in future
so this bug would not fix this problem, FF/TB should start somehow without
dependent extension.

BTW Mozcc_0.9.3.xpi does not require jslib because... it is bundled with it.

Comment 5

[Jens Bannmann]

(In reply to comment #4)
> Should the installing e.g. tagzilla without jslib be another bug ?

The spec only talks about "disabling chains of incompatible extensions", meaning
that when JSlib becomes disabled, TagZilla should be disabled, too. The
em:requires tag opens up a lot of possibilities though, and the exact set of
features built around it must first be determined. When that is done, this bug
could be turned into a tracking bug for the individual parts, or everything is
implemented together.

Some thoughts, for the record:
A check at installation could not tell the user where to download the required
extension (or even its name), and an automated install of the required extension
sounds cumbersome, because we have no way to request a specific version (range)
of an extension from addons.mozilla.org. Just rejecting the package might be
frustrating to the user, so I think the best way to go here would be to
introduce a special disabled-until-required-extensions-installed state. This
would be set not only for freshly installed extensions with unfulfilled
dependencies, but also when for example JSLib is uninstalled/disabled manually
or automatically. Firefox would not allow to enable such an extension by hand
afterwards (only uninstall).

Comment 6

[Benjamin Smedberg]

*** This bug has been marked as a duplicate of 298497 ***

Comment 7

[Przemyslaw Bialik]

(In reply to comment #6)
Hey my bug was first ;)

Comment 8

[Benjamin Smedberg]

And for that I am grateful :-) too bad the technical details got put in the
other bug.