715493 - ACR 1.0.2 breaks AOM Add-ons Search in SeaMonkey

Status: RESOLVED FIXED

Description

[Jens Hatlak (:InvisibleSmiley)]

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.

Comment 1

[Jens Hatlak (:InvisibleSmiley)]

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

[Justin Wood (:Callek)]

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

Comment 3

[David McNamara [:mackers]]

Fixed in r100107

Comment 4

[Jens Hatlak (:InvisibleSmiley)]

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

[Brian King [:kinger]]

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