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)

ACR-1.*

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.
Assignee: nobody → dave
Severity: normal → major
Priority: -- → P1
Target Milestone: --- → ACR-1.0.3
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.
(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.
Fixed in r100107
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
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?
(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.
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.