Open
Bug 1411907
Opened 7 years ago
Updated 2 years ago
Wrong update detection of webextension
Categories
(Toolkit :: Add-ons Manager, defect, P3)
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().
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.
Updated•7 years ago
|
Component: Untriaged → WebExtensions: Untriaged
Product: Firefox → Toolkit
Comment 2•7 years ago
|
||
Not the same symptom but probably related to bug 1407055 and our handling of changes in sideloaded extensions.
Component: WebExtensions: Untriaged → Add-ons Manager
Updated•7 years ago
|
status-firefox57:
--- → wontfix
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.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•