User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 1.1.4322; .NET4.0C; InfoPath.3; .NET4.0E) Steps to reproduce: Developed a scanning plugin with Firebreath SDK, Windows 32 only. Tested it on FF 2.0 through 9.0.1, it works well. Also works in Chrome, Safari & Opera. No version-dependent or browser-dependent issues were encountered. (Deployment via .xpi, different story!) Actual results: Just discovered this: https://wiki.mozilla.org/Features/Add-ons/Add-ons_Default_to_Compatible See also bug 703783 - https://bugzilla.mozilla.org/show_bug.cgi?id=703783 Expected results: If I'm understanding correctly, our plugin with binary components will be *assumed* to be broken, every time FF version (major version??) changes, requiring developer and possibly end-user intervention *to no purpose* - just as Mozilla moves to an insanely frequent release schedule. All because somebody believes without any stated evidence that "Binary add-ons are never compatible between releases". The assumption seems from my employer's POV to be painfully incorrect. Maybe "Not all binary add-ons are compatible between releases"?
At the time this bug was filed, this was true. AMO incorrectly used detection of files with binary extensions to trigger strict compatibility. As of Jan 18th and the following commit, AMO now correctly uses the detection of the use of "binary-components" in the chrome manifest to determine whether to trigger strict compatibility. https://github.com/robhudson/zamboni/commit/1fca769f
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.