Closed
Bug 715493
Opened 13 years ago
Closed 13 years ago
ACR 1.0.2 breaks AOM Add-ons Search in SeaMonkey
Categories
(addons.mozilla.org Graveyard :: Compatibility Tools, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
ACR-1.0.3
People
(Reporter: InvisibleSmiley, Assigned: mackers)
Details
Running a current SeaMonkey trunk build I wondered why the Add-ons Search
functionality was broken. Turns out it's the ACR add-on that breaks it, and
only in SM but not in FF:
Error: formatURL: Couldn't find value for key: COMPATIBILITY_MODE
Source File: jar:file:///home/jens/usr/sm/trunk/omni.ja!/components/nsURLFormatter.js
Line: 131
extensionsOverlayConroller.js line 429 and following do:
if ((envInfo.appName == "Firefox"||envInfo.appName == "Thunderbird")
&& versionComparator.compare(envInfo.appVersion, "9.0a2") >= 0)
{
ACR.Logger.debug("App version >= 9 -- will not use CustomAddonRepostory.jsm");
}
else
{
ACR.Logger.debug("App version < 9 -- will use CustomAddonRepostory.jsm");
This is evil. This breaks when I just look at it! Let's do it like this:
var useCAR = true;
switch (envInfo.appName) {
case "Firefox":
case "Thunderbird":
useCAR = versionComparator.compare(envInfo.appVersion, "9.0a2") < 0;
case "SeaMonkey":
// FF 4 equals SM 2.1, 5 -> 2.2, ..., 9 -> 2.6.
useCAR = versionComparator.compare(envInfo.appVersion, "2.6a2") < 0;
default:
Components.utils.reportError("ACR does not support " + envInfo.appName);
}
if (useCAR)
{
ACR.Logger.debug("useCAR = true -- will not use CustomAddonRepostory.jsm");
}
else
{
ACR.Logger.debug("useCAR = false -- will use CustomAddonRepostory.jsm");
or extend your custom getHostEnvironmentInfo() function in Utils.jsm to also
retrieve nsIXULAppInfo.platformVersion and check against that instead here.
Updated•13 years ago
|
Assignee: nobody → dave
Severity: normal → major
Priority: -- → P1
Target Milestone: --- → ACR-1.0.3
Reporter | ||
Comment 1•13 years ago
|
||
Actually this bug affects SM trunk, Aurora and Beta (all of which have compatible-by-default active, like FF), so I kindly ask you to address this before January 31 (SM 2.7 release date) at the latest.
Comment 2•13 years ago
|
||
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #1)
> Actually this bug affects SM trunk, Aurora and Beta (all of which have
> compatible-by-default active, like FF), so I kindly ask you to address this
> before January 31 (SM 2.7 release date) at the latest.
If the addon isn't fixed by then, we can blocklist its specific version that breaks us, but I'd hate to do that.
Updated•13 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 4•13 years ago
|
||
Do you have an ETA for ACR 1.0.3? SM 2.7 has been released yesterday, so this bug is exposed to users of our stable branch now. :-(
Also, is there a publicly accessible page or bug that lists the ACR roadmap, release dates, or dependencies that needs to be fulfilled until the next ACR version can be released?
Comment 5•13 years ago
|
||
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #4)
> Do you have an ETA for ACR 1.0.3? SM 2.7 has been released yesterday, so
> this bug is exposed to users of our stable branch now. :-(
I just released it now. It might take a bit for the site caches to flush and for it to go live.
> Also, is there a publicly accessible page or bug that lists the ACR roadmap,
> release dates, or dependencies that needs to be fulfilled until the next ACR
> version can be released?
The only page is:
https://wiki.mozilla.org/AMO:Projects/ACR
However, a new spec is in the works to make a brand new, stripped down, ACR that will be designed to work better with Compatible By Default.
Updated•9 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•