Show developers more informative errors when an add-on can't be loaded

NEW
Unassigned

Status

()

Toolkit
Add-ons Manager
2 years ago
6 months ago

People

(Reporter: callahad, Unassigned)

Tracking

(Blocks: 1 bug, {DevAdvocacy})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [DevRel:P3])

(Reporter)

Description

2 years ago
STR:

(Example in the "plus_in_id" folder of https://github.com/callahad/webextension-tests/)

1. Set the "id" field in your add-on's manifest to "foo+bar@example.com"
2. Package the add-on into an xpi
3. Attempt to install the add-on

What Should Happen:

- The add-on installs

What Actually Happens:

- Firefox complains that "this add-on could not be installed because it appears to be corrupt."

Replacing the "+" with "-" results in a working add-on.

This was reported by @Louis_Remi on Twitter: https://twitter.com/Louis_Remi/status/665184130032910336

:andym, do we need an additional bug for providing better diagnostic messages about failures, or do we expect stuff like this to just fall into place naturally with Bug 1185460?

Comment 1

2 years ago
If the add-on fails to load, it would be nice to show the error nicely. Note that jpm will show an error and the browser console will show an error:

1447457738000	addons.xpi	WARN	Invalid XPI: Error: Illegal add-on ID the-id-is-something-that+magopian-swears-doesnt-exist

Exactly what the development flow is for an add-on is expected to be is a bit confusing to me at the moment.

Updated

2 years ago
Blocks: 1226743
Why does this matter?
(The + character in the ID, that is. The bad diagnostic messages should definitely be fixed.)
(Reporter)

Comment 4

2 years ago
(In reply to Kris Maglione [:kmag] from comment #2)
> Why does this matter?

If IDs look enough like email addresses, people are going to naturally try to use sub-addressing. E.g., developer+project@example.com, just like @Louis_Remi did above. Seems like the path of least resistance is to take a line from Burger King and say "have it your way."
I think I'd rather people learn that the IDs do not need to be actual email addresses, so they don't feel obligated to use them. A proper error message should take care of that.

In general, I don't really have any interest in emulating 4th rate fast food chains, so that sounds like a good counterargument to me.

Comment 6

2 years ago
I agree with Kris, let's ensure the rules are simple, documented and enforced. I'd like to see a nice clear message and this case its a matter providing more information instead of just saying its corrupt. This bug belongs in the Add-on manager though.
Component: WebExtensions → Add-ons Manager
Summary: Plus character ("+") not allowed in add-on id, Firefox says add-on appears to be corrupt → If Add-on id is invalid, Firefox says add-on appears to be corrupt
I recently noticed another instance of this confusing "Add-on appears to be corrupt" message: If an XPI has no install.rdf at top level, a doorhanger appears, saying "The addon from could not be installed because it appears to be corrupt" (with no location after "from" in the first case of it I found, which was in trying to reinstall ChatZilla from the cZ build distributed with SeaMonkey in its <appdir>/distribution/extensions directory). No indication of the particular kind of corruption (see bug 1223210 comment #16 sqq. and bug 1233969). The message is of course correct but not very informative, so my argument is analogous to comment #6 with a different kind of "corruption". Here too, a nice clear message would have been welcome.

Of course, tracking all possible cases of add-on corruption might be an endless toil, so maybe the original imprecise message should be kept as a fallback; but we have already identified two specific cases which IMHO deserve a more specific error message:
- The add-on ID contains invalid characters (or maybe: characters other than... with a regexp)
- No install.rdf was found in this add-on.

Another possible case has not yet happened to me, but I can think of it as a third type:
- This file was not recognized as in ZIP format (i.e. Firefox [or Thunderbird or SeaMonkey etc.] did not succeed to unzip it).

Updated

2 years ago
Duplicate of this bug: 1248455

Updated

2 years ago
Summary: If Add-on id is invalid, Firefox says add-on appears to be corrupt → Show developers more informative errors when an add-on can't be loaded
(Reporter)

Updated

a year ago
Whiteboard: [DevRel:P3]

Comment 9

a year ago
I've been having these errors that chrome caught, but not firefox (firefox only showed: extension is invalid):
- icon could not be loaded
- default_locale was specified but not locales

I

Updated

11 months ago
Duplicate of this bug: 1302990

Comment 11

9 months ago
I believe I'm having a similar issue.

When developing, I tried to reload my extension in about:debugging. The load failed and the only error message I got was "There was an error during installation: Extension is invalid".

I ran web-ext lint on my codebase and it produced no errors.

On a hunch, I checked the Browser Console and there was a perfectly helpful error message: "1479348916445	addons.webextension.<unknown>	ERROR	Loading extension 'null': Reading manifest: Error processing background: Error processing background: Property "scripts" is required". (I had accidentally deleted that line.)

I would have loved to see that error message inline when I tried to reload my extension the first time.
You need to log in before you can comment on or make changes to this bug.