strictCompatibility is sometimes ignored




Add-ons Manager
5 years ago
26 days ago


(Reporter: Reşat SABIQ (Reshat), Unassigned)


20 Branch

Firefox Tracking Flags

(Not tracked)




5 years ago
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130326150557

Steps to reproduce:

Steps (using current 2 latest releases):
1. Install Firefox 19.
2. Set up 2 profiles in 2 different accounts on Windows (XP), and install version 19.0.1 from
3. Upgrade Firefox to 20 from one of the profiles.
3.1. Addon installed on that profile is updated OK.
4. Logon to the other account.
5. Launch Firefox, using the other profile where the addon is installed.

Actual results:

XML parsing error (scary as hell) instead of app windows and tabs is shown.

Expected results:

The addon should have been updated before loading the profile.

Comment 1

5 years ago
FYI: I tried this on Linux with 2 profiles in the same user account, but in that case the issue wasn't reproduced.

Comment 2

5 years ago
To make sure, the root cause is clear: the XML parsing error was shown because the addon wasn't updated. It required -safe-mode to recover the profile.

Comment 3

5 years ago
(In reply to Reşat SABIQ (Reshat) from comment #0)
> 2. Set up 2 profiles in 2 different accounts on Windows (XP), and install
> version 19.0.1 from 
PLEASE NOTE, the correct URL to install the addon from is as follows:

P.S. Sorry for messing up the URL in the OP.
So you're saying that the add-on should be either been updated or disabled because it was meant to be incompatible? Because that add-on doesn't specify strictCompatibility in its install.rdf.
It looks like version 19.0.1 and 20.0 both have strictCompatibility set. However, version 19.0 and previous versions don't.

Could it be that you installed 19.0 instead of 19.0.1 in one of the profiles?

Comment 6

5 years ago
I tried this on Windows 7 w/ 2 accounts today, and multiple "post-update"/"secondary" profiles, and wasn't able to reproduce the issue. Given that i hadn't been able to reproduce it on Linux (using tar.bz2 artifacts and profiles on the same account) either, chances are the issue isn't reproducible.

Under the circumstances, i'm self-resolving this bug. I'll also try from scratch on the original XP box: if i happen to reproduce it there i'll communicate it here, otherwise the case can just stay closed.

P.S. I had double-checked the 2nd-account-2nd-profile and it had addon version 19.0.1 and I know what i saw, and I don't drink. :) Perhaps a certain combination of addons, and/or plugins, and/or machine characteristics, and/or prior events on the machine was what really caused an otherwise functioning feature not to function that time. But unless this can be reproduced there can't be an open bug, so i'm marking this as resolved. And hopefully i can't reproduce it anymore, which will mean there's a very high probability nobody else will run into such an issue.
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME

Comment 7

5 years ago
This happened to me again on Linux (following install of a distro-provided upgrade). Something noteworthy that happened in this case is that before the issue happened an error dialog was shown indicating that the download of an update for another must-be-upgraded extension[1] installed on the same profile failed.
This could be an indication that the issue is happening only if there is a connectivity issue during version check[2], or download of the update (and the error dialog and disabling don't happen for extensions without a native component in that case).
I don't recall this 100%, but i may have launched Firefox while the connection was still being established (with a progress indicator being shown), so there may have been a race condition between Firefox starting and the connection being established.

1. The issue has been encountered on pre-existing profiles using the following environments:
1.1. Windows XP
1.2. Linux
2. The issue couldn't be reproduced with brand-new profiles made for troubleshooting on the following environments:
2.1. Linux
2.2. Windows 7
2.3. Windows XP

Chronology (of encountering the issue and troubleshooting): 1.1., 2.1., 2.2., 2.3., 1.2.

[2] Such as:{d5af7e07-9f33-40c7-9234-0b2c2da6ada2}&version=19.0.1&maxAppVersion=19.*&status=userEnabled&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=20.0&appOS=WINNT&appABI=x86-msvc&locale=en-US&currentAppVersion=19.0.2&updateType=98&compatMode=normal

P.S. I'd personally now feel comfortable resolving this bug report only after not having encountered this issue for a couple of upgrades. But frankly, since this appears to be dependent on a certain sequence of events and isn't reproducible in a happy-path workflow, even that wouldn't be a guarantee that the issue no longer exists. If and when i have time, i might try to reproduce the issue again with no connectivity during step 5. in the OP. If it's easy to reproduce the issue that way, then it will be easy to ascertain whether the issue is fixed in a certain release or not.
Resolution: WORKSFORME → ---

Comment 8

5 years ago
I encountered the issue again (for

1. On Windows:
1.1. On 2 profiles.
1.2. I then noticed that AMO had changed 21.0's maxVersion to 22.*, and changed it back to 21.*.
2. On Linux:
2.1. On a few profiles.
2.2. This happened a couple of days after 1.2.'s change back to maxVersion of 21.*.

P.S. I felt compelled to log 889214. If that bug is closed unresolved for any reason, is there any way for me to request that maxVersion isn't messed with for

Comment 9

26 days ago
Per policy at If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Last Resolved: 5 years ago26 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.