Closed Bug 299041 Opened 20 years ago Closed 17 years ago

add a pref to disable installation of extensions not compatible with new EM (install.js only)

Categories

(Toolkit :: Add-ons Manager, enhancement)

Product:
Toolkit
Component:
Add-ons Manager
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: maxxmozilla, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050626 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050626 Firefox/1.0+

Add a pref to disable installation of extensions not compatible with new EM
(install.js only).
The alert could have info like:
"[extension name + ver] could not be installed because it is not compatible with
new EM (install.rdf missing).
Making it default could be considered (most of such extensions would not work
and even if, uninstalling them would not be easy for the average user).

Reproducible: Always
This will also need to take into consideration how patches like the shell patch
which used an install.js will be distributed. I believe that patching using
xpi's is currently not possible due to the work being done on the app update
system but if sending out xpi style patches to the app is needed using anything
other than an install.js becomes very complicated especially if the patch needs
to be removed when upgrading the app as was needed with the shell patch.
I will fill second bug concerning making this pref the default one so the
discussion about doing this would be splitted from this bug and the bugs
blocking the possible new behaviour could then be added to the proper bug.
This bug would be set to block the new bug.
Blocks: 299166
From Darin - the supported instruction set for the new update system is
  add         - copies a file from the archive into the install directory
(possibly replacing an existing file)
  remove      - removes the specified file if it exists
  patch       - apply a binary patch (bsdiff) to an existing file
  add-if      - like 'add', but only applies if a specified test file or
directory exists
  patch-if    - like 'patch', but only applies if a specified test file or
directory exists

So, it appears that extensions with an install.js will not be needed for patching.

Besides old style extensions what other scenarios for toolkit apps if any would
an xpi need to be delivered with an install.js? I'm not sure if this would apply
depending on the approach taken but I believe that plugins call refreshPlugins
from install.js though there is a bug open on refreshPlugins not working currently.
Reasons not to default to this:

-Existing content using install.js (e.g. Java plugin)
-Breaks compatibility with non-EM Mozillas
-Removes a potential fallback if a complicated update is needed
(In reply to comment #3)
Thanks for info :)

(In reply to comment #4)
> Reasons not to default to this:
I think you wanted to comment under Bug 299166 ;)

> -Existing content using install.js (e.g. Java plugin)
one java xpi I know is just an exe hidden into extension (install.js launches
webinstaller)

> -Breaks compatibility with non-EM Mozillas
huh? this bug is not for mozilla

> -Removes a potential fallback if a complicated update is needed
can you give an example, maybe bug should be filled ?
IMO - giving the option to disable via a pref will need to take these issues
into consideration as well since it can allow a user to break existing
functionality ncluding areas outside of extensions since xpi's with an
install.js are used by more than just extensions.
So...

If a plugin is installed using an install.rdf perhaps we can call refreshPlugins
via the em?

I believe the update code no longer allows falling back to using an xpi with or
without an install.js since it has been re-written. I think we are going to have
to rely entirely on the new update code for patching but  may be wrong in this.

A notification similar to the old theme error (not to be confused with the old
old theme error which is non-existent see bug 244684) could be displayed when
attempting to install an extension without an install.rdf.

I have no idea how many exe's are packaged like java but an estimate of how many
would be a good thing to know since this will break them with the pref set.
(In reply to comment #7) 
> I have no idea how many exe's are packaged like java but an estimate of how many
> would be a good thing to know since this will break them with the pref set.
Yeah would be interesting to know but I have a feeling that not much (excluding
spyware xpi's).
BTW is't it a bad practice from the beginning ? to 'cheat' that sth is an
extension while it is only exe packed as extension.
Anyway if this bug would be fixed someday those doing so might be contacted
(probably to remove such extension and provide direct link to exe, ability to
download and run exe is rather the standard one...).
Spellchecker dictionaries are installed with install.js.
http://www.mozilla.org/products/thunderbird/dictionaries.html
(In reply to comment #9)
Bug 254732 may cover this case (\components\myspell\).
BTW The same fix should be also applied when it comes to the \plugins dir.
Bug 254732 was wontfixed so users will be forced to install extensions that are
not easy to uninstall, they won't be visible under EM and other pros of using
install.rdf would not apply :(
Maxx, I really don't understand how bug 254732 is especially related to this
bug. We can fix the problem of library dependencies without installing anything
to the application or system directory.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #12)
Well I should comment under bug 299166 but since discussion has started here and
nobody is commenting under mentioned bug I've put my comments here.
My goal is to allow authors to easy convert their install.js only extensions
(which rely on adding files to appdir/components /plugins and maybe other cases)
into install.rdf ones.
If all extensions could be made (finally) compatible with new EM I would be more
than happy :)
That goal can be accomplished by extending the capabilities of the extension
format; I have already done that for firefox 1.1 by giving extensions the
ability to add searchplugins and NPAPI plugins, and to provide platform-specific
files.
(In reply to comment #14)
Yeah I know about these enhancements and thanks for them :D
You've said that 'Loading dependent libraries directly from an extension
directory' is another bug, is it already filled or not yet ?

No, it is not filed yet. I would like to see an extension that actually needs
that functionality.
(In reply to comment #16)
OK some examples:

appdir/plugins:
- Annodex Viewer plugin packages
http://www.extensionsmirror.nl/index.php?showtopic=2559

appdir/components:
- SpellBound spell check libraries
http://www.extensionsmirror.nl/index.php?showtopic=474

appdir/components/myspell:
- spell check dictionaries (comment #9)
The example plugin and component XPIs you list don't load dependent libraries,
and plain components/plugins already work.

Myspell dictionaries are covered by bug 216382.
Sorry Benjamin for not well enough verified examples...
- Annodex Viewer plugin packages are installed using install.js into
appdir/plugins because Bug 295247 is a new feature (I somehow missed this one)
- the reasons why SpellBound spell check libraries are not installed into
profile are explained in the SpellBound FAQ (http://spellbound.sourceforge.net/faq)
*** Bug 299166 has been marked as a duplicate of this bug. ***
We have now completely removed support for install.js based xpi packages so there is no longer any need for a pref to control this.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.