Add on stops working when increasing version

Add-ons Development
#1

Hello, I’m having some problems with an addon which i hope someone can shed some light on what I am doing wrong.

The situation is as follows, I have a (previously working) addon that stopped working after i changed it’s version in the manifest.json, signed and packaged it (at “https://addons.mozilla.org/pt-PT/developers/addon”) as a new version.
When signing and packaging the addon it passes all validations as in the image below:

imagem
imagem.png1005×395 19.5 KB

The addon works if i point to its folder when loaded as a temporary addon but it does not work if i point to a .zip file containing the same as the folder.
Also, if i install the previous version, it works as expected.

It is an addon that handles native messaging and the native code suffered no changes whatsoever. As for the addon only the “version” in the manifest.json got changed.

Thanks for the attention, and let me know if more details are needed

#2

The link just points to the logged-in users add-on overview. That is rather useless. It may be helpful to see the add-ons code.

There is quite a number off things that can go wrong with native messaging. Are you explicitly setting the same applications.gecko.id in both versions?

#3

Hi,
Yes the gecko id is being set in both versions, I assume there are no problems with the code itself as it remained unchanged between both versions. Additionally the addon works if i install the previous version or if i install the new version as a temporary addon.

Only the version line in the manifest.json (pasted below) changed.

{
      "name": "Extension",
      "version": "1.1.8b1",       **-> this is the only line that changed between versions**
      "manifest_version": 2,
      "description": "Send a message to a native application.",
      
      "applications": {
    		"gecko": {
          "id": "#ID#",       
    	  "strict_min_version": "50.0"
        }
      },
      
      "content_scripts": [
    	  {
    	  "all_frames": true,
          "matches": ["<all_urls>"],
          "js": ["browserScript.js"]
        }
      ],
      
      "background": {
    	  "scripts": ["background.js"]
      },
      
      "icons": {
        "128": "image.png"
      },
      "permissions": [
        "nativeMessaging", "tabs"
      ],
      "browser_action": {
        "default_icon": "image.png"
      },
      "web_accessible_resources" : ["injectedScript.js"] 
      
    }
#4

Ok, then please specify what “stopped working” means.

#5

Are you certain the format is correct?

My take of

is that the version parts are compared as
number - string - number - string
and it looks like yours is
number - number - string

#6

Interesting. According to the linked article, Firefox won’t be able to compare versions of the format <major>.<minor>.<patch><channel><build> correctly (as you said, the <patch><channel><build> would be cast to a number before comparing).

However, I have used that format for quite a while and also set up automated non-AMO updates based on it. That always worked as intended.

But I think that is besides the point. This problem is not about comparing versions.
We still need to be told what “stopped working” means.

#7

Hello, yes “stopped working” is indeed too vague of a description, I am sorry for that.

What I meant is the addon no longer “injects” it’s code in the page, more specifically the code from “injectedScript.js” (pasted below) is not being added to the page.

    window.extensionInstalled = function(){
    	return true;
    }

The page uses this function to determine if the extension is installed and decides on the functionalities that it can provide to the user.

#8

Firefox would compare <patch><channel><build>, essentially the last segment if it contains non-numbers, by ASCII values.

#9

Ok, and how do you inject that?
(Also, why? Just add a class to the <html> element or something like that.)

#10

I think both @Mittineague and I misread that documentation:

A version string consists of one or more version parts, separated with dots.

Each version part is itself parsed as a sequence of four parts: <number-a><string-b><number-c><string-d>.

So a version string can consist of up to 16 atomic “things”.

It’s a bit confusing because the word “part” is used with more than one meaning.

But bottom line, the string used here works exactly as I would hope and expect.

1 Like
#11

That’s not how extension versions are handled though, afaik. Updates to extensions with letters in their version string are almost fully ascii sort based and not numbers.

#12

It is “injected” by setting the injectedScript.js as an web accessible resource
"web_accessible_resources" : ["injectedScript.js"]

And yes it could be done in a various manner of ways, but I still do not understand why it is properly injected when i install it as a temporary addon but is not injected when i package it into an .xpi at the mozilla developers dashboard.
The only .xpi that does work is the one of version 1.0 as i previously said.

#13

Well, this time, that is really what the documentation says. With the string 1.1.8b1,
1 and 1 are the first two (purely numeric) parts, 8 is <number-a> of part 3, b is <string-b> of part 3 and the last 1 is <number-c> of part 3. Only the b will be compared as a string.

#14

That is only how you expose it, you still need to add it to the page somewhere. How do you do that and are you sure it is happening?

#15

Yes i am quite sure it happens.
If I install the latest version .xpi that I packaged in the developers dashboard i get:

imagem
imagem.png758×343 20.3 KB

And when i unzip that same .xpi to a folder and install it as temporary i get:

imagem
imagem.png750×356 21.3 KB

#16

So in both cases, the <script> tab is added to the body (and has the same src), but with the changed version, the script doesn’t load?

#17

Yes that appears to be the case, the script tag is added to the body in both the cases. Furthermore, if i access the url of the file (moz-extension://[extension id here]/injectedScript.js) with the changed version i get the page not found error, but with the original version i get,

window.extensionInstalled = function(){
	return true;
}

which is the expected content of the file.

#18

Ok, then check if the file is actually in the new .zip file (open the .xpi as ZIP archive).
If it is, did you pack both versions the same way?

#19

As the snippet below shows both .xpi files contain the same files (1.0 on the left and 1.1 in the right)
imagem

Both versions were packaged using firefox developers dashboard.

#20

casing of the file has changed. injectedScript.js vs. injectedscript.js

2 Likes