522111 - ignore extensions.checkCompatibility for extensions with binary components

Status: VERIFIED DUPLICATE of bug 422939

(Toolkit :: Add-ons Manager, defect)

Description

[Justin Dolske [:Dolske]]

Binary components are often inherently version-specific, and forcing compatibility is likely to just lead to a crashy browser. We could just ignore this pref for such extensions, as it's a risky footgun in this case.

Comment 1

[Benjamin Smedberg]

Related to, but somewhat easier than bug 505983. We'd need some way to tell the EM what binary components are, but I suppose we could just hardcode a list of file extensions for now.

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Without observing the preference, how would someone check for compatibility before a release is out? Modify their version number accordingly?

Comment 3

[Jesse Ruderman]

They'd need to compile against the new version anyway, wouldn't they?

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Hm, good point; is that universally true, or only true when the binary component calls in to ours, as opposed to being referenced by an add-on? I'm thinking of things where the binary component is used for computation but the add-on is used for the UI pieces.

I worry about complicating the testing story here, but I think that the overall liklihood of a binary add-on causing problems is pretty high. Copying Shaver for an additional opine, here. Shaver, do note that bug 521905 is also marked as a blocker, and may be a sufficient fix.

Comment 5

[Johnathan Nightingale [:johnath]]

(In reply to comment #4)
> Hm, good point; is that universally true, or only true when the binary
> component calls in to ours, as opposed to being referenced by an add-on? I'm
> thinking of things where the binary component is used for computation but the
> add-on is used for the UI pieces.

Yeah, it would be nice to not throw out the "I use self-contained or system DLLs to do smart things" babies with the "I compile against the shifty sands of XPCOM" bathwater.

OTOH, if it happened that the only way to fix this was to nuke support for extensions.checkCompatibility=false on all things that involve a binary, my first reaction is that I would probably take that trade. We're not talking about breaking the extension, we're talking about breaking the extensions' ability to be loaded against its own compat claims.

I don't think it should, though, right? An addon that shipped with a DLL that it accessed through js c-types but never tried to load as a binary component would still be fine under a suggestion like Benjamin's in comment 1, wouldn't it?

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Bug 521905 is blocking, and I want to make sure that we think this through before we block on it. When we have good answers to the questions in comments 4 and 5, and a plan of attack, please renominate.

Comment 7

[Jesse Ruderman]

Would it be sensible to add an extra pref controlling binary components?  Even a per-extension or per-Firefox-version pref?