I’ve been trying to increment the version # in my add on, and testing it before uploading it to AMO for approval.
But every time I increment the version # and test it on my firefox 43, it says the add on is corrupted.
Why does merely incrementing the version number corrupt the file? I’ve never had a problem with this before until FF 43 came out.
Any change to any folder/file will break the signature of the add-on.
You can test your add-on in the Developer Edition or Nightly where you can disable signature enforcement.
Thanks. I tried it in the Developer Edition, with the new version incremented in install.rdf.
It works. And I was even able to restart the FF Developer Edition browser, and it would continue working.
Does this mean users would be able to restart their non-developer edition FF 43 browsers, and the add on would continue working?
Is there a signature warning for your add-on in the add-on manager?
There’s a warning saying “Perapera Chinese could not be verified for use in Firefox Developer Edition. Proceed with caution.”
I guess there you have your answer.
The signature is broken and therefore the add-on will not work in stable or beta versions of Firefox. It merely works in Developer Edition or Nightly because signing enforcement can be disabled there.
Ok. So what my solution? Next steps?
Oh wait, with the changed install.rdf the warning will be showed anyway.
You need to figure out why your add-on gets disabled even after it was signed. It probably is because someone or something changes the add-on contents, that’s why I proposed to remove the “unpack” flag. Non-unpacked add-ons cannot change their own contents (easily). Unpacked ones on the other hand can and I guess that’s what’s happening here.
Two things.
The current working version being distributed to the users via AMO as of today - its signature is also broken. I get the signature warning in the Add-ons Manager in Developer Edition.
Removing the unpack flag (or setting it to false) breaks the add on. I get an error that says “Error: Could not find or open chineseperakun@gmail.com/dict.sqlite”.
dict.sqlite is a database file within the xpi file, in its root folder. So the problem is that disabling the unpack flag, the add on is not able to open that database file (or any other file within the xpi file), so the add on doesn’t work.
Do you write to that sqlite file from within the add-on as well?
I’m not sure. I don’t think so because it is essentially a dictionary being used for translating Chinese to English.
But accessing that sqlite file would probably create a .wal (write ahead log) or shm file that would break the signature.
Even it does that, is there a way to prevent the signature from breaking?
The only way is to not change any folder or file within the add-on.
The way this add on works is when the user activates it, the add on creates an index for the dictionary. This is done by executing a SQL query. It enables the add on to instantaneously display english translation popups on the screen as the user mouse-overs chinese words.
We need a way for this to work without breaking the signature
Can anyone help?
Simply change the location where the sqlite database is stored, by coping or creating it on startup if it not already exist. Best place is probably somewhere in the current profile directory.
While not the best solution for a read-only database, it could work. However, you need to make sure all created files are removed when the add-on gets disabled or uninstalled.
Thanks lieser, I’ll try this and let you guys know.
I indexed the sqlite database separately from the add-on, and replaced the unindexed database with the indexed one.
My thinking here is that the add-on will NOT index (or modify) the sqlite database, and therefore will not break the signature.
However, I still need a new signature for the new sqlite database. It still points to the old signature and I still get the signature warning in FF Developer Edition.
Will I get a new signature when I submit the updated add-on to AMO for review?
Yes, every version gets signed independently.