Closed Bug 291791 Opened 20 years ago Closed 20 years ago

removing install.rdf deletes the whole extension directory

Categories

(Toolkit :: Add-ons Manager, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: asqueella, Assigned: bugs)

References

Details

(Keywords: dataloss)

If you register an extension by creating a text file in profile/extensions/
pointing to the extension location, and then remove install.rdf at that
location, EM deletes the whole extension directory.

I can see the reasoning behind this. I argue this should not be done though.

One of applications for this feature (ability to easily register files in
location outside user's profile), as I see it, is using it to develop
extensions, in a location separate from your profile. That allows to test the
same latest code in different profiles (e.g. sometimes you want to check the
behavior of your extension on a clear profile or when it runs with another
extension). It also allows you to have shorter path to your extension, e.g.
"x:\dev\extension" instead of "c:\profile\extensions\guid\chrome" or even
"c:\documents & settings\name\application
data\mozilla\firefox\profile\extensions\guid\chrome".

So, one stores all of his project files (including those not directly used by
firefox) in a single directory, which happens to also contain install.rdf.
(That's what I've been doing for quite a long time, first by editing chrome.rdf,
then using absolute paths in chrome.manifest). Then he decides to temporarily
rename/move install.rdf and - oops - all of the project files are gone. I was
lucky enough to be using CVS for that project, but you're responsible for
deleting my todo file and archive of releases ;-)

The main reason I think EM shouldn't do this is that it /didn't create/ the
directory referenced in the GUID file. Generally, software shouldn't delete what
it didn't create. I can understand deleting folders like
profile/extensions/{GUID} on uninstall. They are in Firefox's profile and
usually it created it on installation. But the folders referenced from a
text-file there do not "belong" to Firefox, therefore it has no right to delete
them.

I hope you can see my point.
Yes, this is not the intended behavior.
Flags: blocking-aviary1.1+
QA Contact: bugs → benjamin
Depends on: 291831
Fixed by patch in 291831
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Also if you uninstall the extension using FF Extension Manager the development
directory gets deleted. You need some way to destinguish development from
regular installs. I got caught because I was about to package the directory, so
I removed the extension so that I could re-install a jar version. This will be
normal usage. (I had a backup phew!)
Peter, that's a different issue, please file a separate bug if you are sure you
can reproduce it with a recent build.
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.