Closed
Bug 502127
Opened 16 years ago
Closed 7 years ago
Addon Manager does not inform of compatibility problems for Builds with Pre-Installed Extensions on first start.
Categories
(Toolkit :: Add-ons Manager, defect)
Tracking
()
RESOLVED
INACTIVE
People
(Reporter: cbook, Unassigned)
References
Details
During the Partner Repack Testing with pre-installed Extensions i noticed that Users do not get any warning when they install a Firefox Build with Pre-installed Extensions and this Extensions are not compatible with the Build (like a max-version 3.1b3 toolbar in a Firefox 3.5 Build).
Also in this scenario is no UI notice that a Add-on was disabled because of compatibility problems. So as example a user never realize that there should be a toolbar etc, unless he checks the addon-on Manager to that a Add-on is disabled.
So i think we should have the Compatibility Warning/Information Window (like we do after Updates) also when a Extension was disabled on the first start - like in the pre-install case.
This would help Partner Builds a lot when we do Version Upgrades like 3.5
Comment 1•16 years ago
|
||
Why would the Firefox build ship with an incompatible extension?
Comment 2•16 years ago
|
||
AMO now allows for compatibility updates which allows authors to flag an extension as being compatible with a specific version of Firefox without modifying the hosted extension. As a result the latest version of the extension hosted on AMO that is compatible may not have an adequate MaxVersion. Firefox doesn't check for the extension compatibility on AMO, it only looks at the local version, which can create some confusion as it throws the compatibility error on install. The install.rdf could be modified, but then you'd have a version that's different than what's on AMO, which is something we'd prefer to avoid.
Comment 3•16 years ago
|
||
This behaviour would significantly slow down the first startup of the new install of Firefox while it has to contact AMO for the updated compatibility information. This seems even less desirable to me than fixing the install.rdf in the repack.
That said this is something that we probably want to do for globally installed add-ons anyway.
Depends on: 454876
Comment 4•16 years ago
|
||
adding fligtar to weigh in to see if the AMO side might be able to automagically modify MaxVersion in the extension when updated. that would solve things, but I can see it causing problems for signed extensions.
Comment 5•16 years ago
|
||
This has been discussed a good bit before, and we've always stayed away from modifying the files the user submits. Signed extensions would cause problems, the files on the developer's computer/repository would no longer be up to date for other/future builds, and as a developer it just would feel weird to me to have AMO change stuff I submitted.
I'll think about it some more for only changing the maxVersion though, as we seem to be getting a huge increase in the number of people that are having problems with install.rdf and AMO reporting different maxVersions.
Comment 6•15 years ago
|
||
Dave, this is exactly the same problem we have reported yesterday with Mozmill on bug 633189. You have wontfixed our bug, meanwhile we moved it to Testing/Mozmill to at least have a workaround.
It strikes me a bit that repacks would have to modify XPI files to make them work with the shipped version.
Can we get a final solution for this issue?
Hardware: x86 → All
Comment 7•15 years ago
|
||
Partner repacks and globally installed extensions are a problematic case, but I still don't think the right solution is to show the current compatibility UI for new users, I think it creates a bad experience. Particularly for repacks they have the ability to ship an extension that is marked as compatible.
I think we should consider this as we move forward with the proposal in bug 596343 which is something we likely want to show for new users as well as existing users on upgrade.
Depends on: 596343
Comment 8•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
•