ACR 1.0.2 breaks AOM Add-ons Search in SeaMonkey

RESOLVED FIXED in ACR-1.0.3

Status

addons.mozilla.org Graveyard
Compatibility Tools
P1
major
RESOLVED FIXED
7 years ago
2 years ago

People

(Reporter: InvisibleSmiley, Assigned: mackers)

Tracking

ACR-1.*
ACR-1.0.3

Details

(Reporter)

Description

7 years ago
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

7 years ago
Assignee: nobody → dave
Severity: normal → major
Priority: -- → P1
Target Milestone: --- → ACR-1.0.3
(Reporter)

Comment 1

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

Comment 3

7 years ago
Fixed in r100107
Status: NEW → ASSIGNED

Updated

7 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Reporter)

Comment 4

7 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

7 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.
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.