User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0 Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0 ID:20110318052756 Add-on versions displayed in the add-on entries when installations launch are incorrect - usually shown as 5 digit integers. Reproducible: Always Steps to Reproduce: 1. Find some random add-on in AOM search pane, remember its version. 2. Add it to some collection. 3. Switch to that collection, click Install for the remembered add-on, watch for the version number displayed next its name.
Assignee: nobody → briks.si
Severity: minor → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Target Milestone: --- → BW-2.0.2
Version: unspecified → BW-2.0
This may (or may not) be fallout from not having the data in the Collections API (bug 642882). As a workaround, we may be able to hide the version during install. When the install is complete, it reverts to the correct version.
Is this related to bug 647715?
(In reply to comment #2) > Is this related to bug 647715? Perhaps, but I don't see a direct connection. Do you?
(In reply to comment #3) > Perhaps, but I don't see a direct connection. Do you? I asked because I noticed you had suggested a connection between this bug and the bugs relating collections API deficiencies, so I thought add-on compatibility data could fall into that same pitfall along with add-on version data. However bug 647715 (add-on compatibility) is not present in FF 3.6, so I guess the API is likely sufficient for its purpose. In Massive Extender for FF 4 I had to add an option to request compatibility data from AMO search API (similarly to a suggested workaround to the collections API deficiency in bug 639904) because bug 647715 is pretty nasty - especially so for mass installs: imagine installing a lot of incompatible add-ons that need to be cleaned up in AOM. But that's kind of clumsy hack.
r90220 has a hacky fix for this - you will see the weird version number pop up briefly then disappear. this is because of asynchronicity issues; the addon manager notifies the addon binding of the weird version number independently of any code in our overlay. the only way around that I can think of is to extend the default binding - probably a disproportionate amount of work for this fix. maybe it's better if we can get a fix checked in to the addon manager api at source
(In reply to comment #5) > r90220 has a hacky fix for this - you will see the weird version number pop > up briefly then disappear. We'll keep this for now, but leave this open until a better fix is in. > this is because of asynchronicity issues; the addon manager notifies the > addon binding of the weird version number independently of any code in our > overlay. > > the only way around that I can think of is to extend the default binding - > probably a disproportionate amount of work for this fix. I don't think we want to go there. > maybe it's better if we can get a fix checked in to the addon manager api at > source Please go ahead and file that bug, explaining the issue and what you think the fix in the Add-ons Manager should be.
Status: NEW → ASSIGNED
Target Milestone: BW-2.0.2 → BW-2.0.3
Had another look at this and turns out it was an easy fix after all. Not sure why I missed it before. r91665
This is in version 2.0.2 which was released yesterday.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.