1310439 - WebExtension-based addons are permanently deleted in case of syntax error

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[Marat Tanalin]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20161014004013

Steps to reproduce:

Firefox Developer Edition (Aurora) and Nightly PERMANENTLY (not even to Recycle bin) delete WebExtension-based extensions from disk without prior notice in case of there is a syntax error in JavaScript code or addon's manifest.

For example, if the "matches" of addon's manifest entry contains `*.` instead of correct `*` as host, Firefox deletes the extension.

JS errors not always (not all errors?) result in deleting, but sometimes do.

I've already lost my work in progress several times, so I'm now forced to backup the addon each time I make any changes.

That's incredibly annoying, confusing and upsetting.

Who is that ingenious human invented that exciting behavior? What's the point?

Could you please STOP destroying addon developers' work this way? Thanks.


Actual results:

The extension is deleted when starting Firefox.


Expected results:

The extension should not be deleted. Just an error should be reported to console if needed.

Comment 1

[Kris Maglione [:kmag]]

How are you installing the add-ons that they're being deleted? We only ever delete add-ons from the profile extensions directory. It shouldn't ever affect development copies.

Comment 2

[Marat Tanalin]

(In reply to Kris Maglione [:kmag] from comment #1)

The extension is a folder in the directory of my profile of course. FWIW, I don't use the "temporarily install addon" feature since it's not quite usable and may really be needed SOLELY for release and beta versions.

I use Developer Edition of Firefox, it's edition for (surprisingly) _developers_, and it allows to disable addon signing and, AFAIK, will continue to allow in the foreseeable future. So there is nothing that should prevent development version of an extension from working as is in the profile directory.

Deleting extension is pointless and harmful. An extension with a syntax error should just be ignored or disabled -- at least in Developer Edition and Nightly versions of Firefox. Deleting developer's work without prior notice is literally hostility (if not backstabbing) against them that just discourages them from developing addons whatsoever.

Comment 3

[Kris Maglione [:kmag]]

Well, I can't prevent you from developing add-ons that way if you so choose, but it's not a supported development flow. Extensions placed directly in the profile extension directory are owned by the add-on manager, and are subject to things like updates, and removal when they're uninstalled or found to be corrupt.

If you want to install an unpacked extension for development, you can use a symbolic link or proxy file[1], the new UI added in bug 1185460, or the web-ext tool[2].

[1]: https://developer.mozilla.org/en-US/Add-ons/Setting_up_extension_development_environment#Firefox_extension_proxy_file
[2]: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/web-ext_command_reference

Comment 4

[Marat Tanalin]

> If you want to install an unpacked extension for development, you can use a symbolic link or proxy file[1]

Thanks, Kris, proxy file looks like a very nice feature. Is it GUARANTEED that the extension directory (which the proxy file points to) will NOT be deleted by Firefox when using a proxy file?

Also, I've just tested the proxy-file feature, and looks like Firefox now deletes the proxy file itself in the same situation, so I'm forced to recreate the file each time when there was just a syntax error (e.g. a typo in manifest) which is still annoying (though fortunately much less destructive).

> the new UI added in bug 1185460

Is that documented somewhere?

> Extensions placed directly in the profile extension directory [...]
> are subject to [...] removal when they're [...] found to be corrupt.

It's still unclear what's the entire point of DELETING extension. Why not just DISABLE (probably the most obvious and unobtrusive option) or IGNORE it instead of destroying irreversibly? I believe that wasn't a random decision and has a substantive reason. What's that reason?

Comment 5

[Kris Maglione [:kmag]]

(In reply to Marat Tanalin | tanalin.com from comment #4)
> > If you want to install an unpacked extension for development, you can use a symbolic link or proxy file[1]
>
> Thanks, Kris, proxy file looks like a very nice feature. Is it GUARANTEED
> that the extension directory (which the proxy file points to) will NOT be
> deleted by Firefox when using a proxy file?

Yes, the target directory is guaranteed not to be deleted, and the add-on is
guaranteed not to be updated.

> Also, I've just tested the proxy-file feature, and looks like Firefox now
> deletes the proxy file itself in the same situation, so I'm forced to
> recreate the file each time when there was just a syntax error (e.g. a typo
> in manifest) which is still annoying (though fortunately much less
> destructive).

That shouldn't be the case in Firefox 45+ (bug 1195353).

> > the new UI added in bug 1185460
>
> Is that documented somewhere?

Not yet. It only landed a few days ago.

> > Extensions placed directly in the profile extension directory [...]
> > are subject to [...] removal when they're [...] found to be corrupt.
>
> It's still unclear what's the entire point of DELETING extension. Why not
> just DISABLE (probably the most obvious and unobtrusive option) or IGNORE it
> instead of destroying irreversibly? I believe that wasn't a random decision
> and has a substantive reason. What's that reason?

I don't know the exact reason behind the original decision. This behavior is
at least 8 years old. But, in general, the contents of the profile extensions
directory is supposed to match the state of the extensions database. If there
are file changes at startup, we scan the contents of the directory and try to
reconcile them with the database. If the add-on is corrupt, we can't do that,
since we can't even parse its metadata. And since the presence of a file in
that directory that isn't in the database is an error, we remove it.