Closed
Bug 762929
Opened 13 years ago
Closed 7 years ago
Do not overwrite local information about addons with info from AMO
Categories
(Toolkit :: Add-ons Manager, defect)
Tracking
()
RESOLVED
INACTIVE
People
(Reporter: BenB, Unassigned)
References
Details
Firefox currently on startup fetches information about installed addons and uses that to replace the local information about them (in extensions.sqlite). This is intentional (bug 586591), yet wrong (broken by design).
The information in install.rdf matches exactly the addon that the user installed and confirmed the install for. Thus, this is what must be listed in the "installed extensions" dialog. Information on AMO may refer to other version, other extensions or other authors altogether. You MUST NOT replace information about local addons with info from AMO.
We had exactly that case now: Distributing an addon, in several variants, with official Mozilla approval, but on channels other than AMO. Now, we're in the process of adding it on AMO, but the process hasn't finished yet, and the information on AMO is still stubs. Nevertheless, Firefox already replaces the info on live Firefox installations (we have a few million installations) with the stub info. This was overwriting even the author and thus the copyright information. This means Mozilla removes the copyright from already installed addons and replaces it with another one. This must NEVER EVER happen. It's a copyright violation.
We must not touch other people's products, be it name, description, author or anything. The fact that you *think* the AMO ext author is the author of the installed extension does not matter. Also, whether AMO notices this at some point and takes action is irrelevant.
Reproduction:
1. Fred Foo creates foo.xpi, ID "123456", author "Foo Corp, Inc (c) 1998"
2. Loo Luser installs foo.xpi from "Foo Corp"
3. Boo Imposter uploads his own addon on AMO, ID "123456", author "Boo Imposter (c) 2012"
4. Loo Luster looks at Firefox "installed addons"
Actual result:
"Boo Imposter (c) 2012" as author
Expected result:
"Foo Corp, Inc (c) 1998" as author
Comment 1•13 years ago
|
||
We use data from AMO for a lot of things, not just the common name/description/author info that's displayed. Much of the data we use isn't available elsewhere, or can't be available elsewhere. Screenshots, reviews/ratings, payment/donation information, strings in other locales, and compatibility overrides (without which, we wouldn't have compatible-by-default addons). We certainly do want to keep all that data for addons on AMO (and for compatibility overrides, even addons not on AMO).
One issue is that the only method for matching addons to what's in AMO's database is the addon's ID. So no, we can't know with 100% certainty whether an installed addon is the same as the addon we think it is on AMO. This is something I'm hoping signed addons can eventually help solve.
In the meantime, setting extensions.<ADDON-ID>.getAddons.cache.enabled=false will disable fetching info from AMO for a given addon (though, take note of bug 762881).
As for copyright/trademark issues, you should contact the legal team. I believe this page has all the relevant information: https://www.mozilla.org/en-US/about/legal.html
Reporter | ||
Comment 2•13 years ago
|
||
Reviews: As addon owner, I don't want reviews for installed addons, and as user, they don't provide me any benefit, because I've already made my decision. Reviews are important before I install.
Screenshots: Ditto.
Strings in other locales: I assume you mean translation of install.rdf (not DTDs for the addon UI)? If the former, it should display the very same strings that were used when installing the addon (which the user obviously understood). For rationale, see initial description. The name and description are critical, and must be *exactly* what was installed, and must not be changed after the fact.
> In the meantime, setting extensions.<ADDON-ID>.getAddons.cache.enabled=false
> will disable fetching info from AMO for a given addon (though, take note of bug 762881).
We do that now, but the damage was already done.
This must be the default behavior. The current default behavior is simply incorrect, for the reasons given.
> As for copyright/trademark issues, you should contact the legal team.
If I want to sue Mozilla, I'd take that course, yes, but that's not my goal. I am just informing you that the current behavior by design can, did and will lead to displaying seriously wrong information. Copyright violations are one of the consequence and reason (but not the only one) why it must be changed.
Reporter | ||
Comment 3•13 years ago
|
||
In general, you seem to be coalescing the addon installation from the Firefox UI and the display of installed addons. That's materially wrong, and leads to the problems listed in the initial description. Please separate them. The UI code can be the same (if certain irrelevant UI parts like reviews display are disabled), but the data source must be different.
Reporter | ||
Comment 4•13 years ago
|
||
(...because it is inherently different. I want to know what I have installed, not what AMO has, which may well and indeed is different from what I have locally.)
Updated•12 years ago
|
Reporter | ||
Comment 5•10 years ago
|
||
We just had another internal bug filed: We were supposed to change the icon. We did. Still, the addon page within Firefox showed the old icon. That makes testing extremely confusing. It's just wrong.
Reporter | ||
Comment 6•10 years ago
|
||
Just the emphasize: This is just materially wrong. What is installed doesn't necessarily match what's on AMO. You can't just say "it should", because there are too many valid cases when it doesn't. Particularly given the pittyful review situation at AMO.
Comment 7•7 years ago
|
||
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INACTIVE
You need to log in
before you can comment on or make changes to this bug.
Description
•