Open Bug 1411907 Opened 7 years ago Updated 2 years ago

Wrong update detection of webextension

Categories

(Toolkit :: Add-ons Manager, defect, P3)

56 Branch
Unspecified
Windows
defect

Tracking

()

UNCONFIRMED
Tracking Status
firefox57 --- wontfix

People

(Reporter: vgolynets, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171002220106

Steps to reproduce:

We have a signed webextension that would like to distribute using own installer via Windows registry mechanism i.e. https://developer.mozilla.org/en-US/Add-ons/Adding_extensions_using_the_Windows_registry

Let say we installer with our xpi file of 1.0.0.0 version i.e. in manifest.json file we have "version": "1.0.0.0".
Close Firefox, install xpi, for example, put our xpi as C:\Program Files (x86)\MyProduct\MyProduct.xpi.
Then run Firefox, it shows notification that new extension available, click to enable it. Extension works as expected.

Next let say we cut new installer with xpi file of 1.0.1.0 version, i.e. manifest.json file has "version": "1.0.1.0".
Close Firefox, install xpi into the same path i.e. C:\Program Files (x86)\MyProduct\MyProduct.xpi.
Then run Firefox. In about:addons we can see that extension updated and have version 1.0.1.0.
But internally at startup our background JS code uses call of chrome.runtime.getManifest() to read extension manifest and check version field. In our case getManifest() returns old manifest i.e.  "version" field still has "1.0.0.0" value.
As a result user see notification from our extension that update 1.0.1.0 is available although he already installed it.

Restart Firefox, now chrome.runtime.getManifest() returns valid object with actual version.
So, in order to apply update user have to restart Firefox twice. Looks like after first restart Firefox returns some cached value of manifest.json file?

We also tried following workaround.
Close Firefox, install 1.0.0.0 version and store xpi as C:\Program Files (x86)\MyProduct\MyProduct-1.0.0.0.xpi file.
Then run Firefox, it shows notification that new extension available, click to enable it. Extension works well.

Then close Firefox, install 1.0.1.0 update and store xpi as C:\Program Files (x86)\MyProduct\MyProduct-1.0.1.0.xpi file i.e. file name changed.
Run Firefox, use does not see our extension although in about:addons we can see extension enabled and it shows proper 1.0.1.0 version.
Restart Firefox, now extension is loaded and we have no issues around invalid "version" field in chrome.runtime.getManifest().
OS: Unspecified → Windows
There is another effect of described issue. For example, if instead of Windows Registry approach try to install xpi file as "C:\Program Files (x86)\Mozilla Firefox\browser\extensions\MyProduct@mycompany.com.xpi", then after update from 1.0.0.0 to 1.0.1.0 version extension's code become updated, but in about:addons user see old version value i.e. 1.0.0.0 and we again have issue about improper value of "version" field returned by chrome.runtime.getManifest() method.

Also in this way any further Firefox restarts do not help us, user still see old version in about:addons and call of chrome.runtime.getManifest() returns old manifest too.
Component: Untriaged → WebExtensions: Untriaged
Product: Firefox → Toolkit
Not the same symptom but probably related to bug 1407055 and our handling of changes in sideloaded extensions.
Component: WebExtensions: Untriaged → Add-ons Manager
Priority: -- → P3

Due to this wrong updates of webextension I have lost the whole data of our extension of https://sanantoniobikeshare.org/best-bike-mirrors/ we developed a custom extension for our self so that we could make our work easy. But the wrong updation made us confused and we lost the data and basic codes.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.