647804 - Installation progress for add-ons displays weird add-on versions. (Firefox 4)

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Collector Extension, defect, P2)

Description

[Dimitri Saltanov]

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.

Comment 1

[Brian King [:kinger]]

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.

Comment 2

[Dimitri Saltanov]

Is this related to bug 647715?

Comment 3

[Brian King [:kinger]]

(In reply to comment #2)
> Is this related to bug 647715?

Perhaps, but I don't see a direct connection. Do you?

Comment 4

[Dimitri Saltanov]

(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.

Comment 5

[David McNamara [:mackers]]

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

Comment 6

[Brian King [:kinger]]

(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.

Comment 7

[David McNamara [:mackers]]

Had another look at this and turns out it was an easy fix after all. Not sure why I missed it before.

r91665

Comment 8

[Brian King [:kinger]]

This is in version 2.0.2 which was released yesterday.