Add-on approved but not signed

[derenrich]

Describe the problem and steps to reproduce it:

I wrote a new add-on (https://addons.mozilla.org/en-US/firefox/addon/ao3-history/) and uploaded it to AMO. The add-on isn't user installable.

What happened?

Installation fails across multiple different computers on different internet connections. The error is "Download failed. Please check your connection.". If you force the download via save-as and then try to install the xpi then you get a different error: "The add-on could not be installed because it isn't verified."

What did you expect to happen?

The add-on should just install. If you inspect the XPI by unzipping it you will notice it isn't signed.

Anything else we should know?

https://addons.mozilla.org/en-US/firefox/addon/ao3-history/

[wagnerand]

This add-on was auto-approved but not signed. @diox or @eviljeff Would one of you have time to look into what happened here?

[derenrich]

(I also opened a bugzilla ticket https://bugzilla.mozilla.org/show_bug.cgi?id=1527496 for this)

[diox]

A couple things we noticed:

• The manifest uses browser_specific_settings
• We were able to reproduce on dev & stage (Edit: and locally). At submission time, it looks like no category is offered. Still, the add-on does end up in awaiting review state, and then in approved state after auto_approve processes it. Both the fact that categories were missing and that it didn't prevent the add-on from reaching awaiting review status are weird.

[derenrich]

is there anything i could change about the add-on to avoid this? it's not clear to me what I'm doing that's "weird".

[wagnerand]

@derenrich this is still under investigation. We'll update the issue as we find out more.

[EnTeQuAk]

So, we found the problem on our end and it's a mixture of various smaller bugs and behaviours that lead to this.

@diox mentioned most of that in #6407

Generally, there is a workaround for this in the short-term: Either replace the key browser_specific_settings with applications or, if that's something you'd be able/willing to do, bump the strict_min_version to 48.0. Both will result in a correctly signed version.

[derenrich]

brilliant! i just bumped the version and now it works

[diox]

#6407 and #6409 should prevent this from happening in the future.