Closed Bug 522111 Opened 12 years ago Closed 10 years ago

ignore extensions.checkCompatibility for extensions with binary components

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 422939

People

(Reporter: Dolske, Unassigned)

Details

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.
Flags: blocking1.9.2?
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.
Without observing the preference, how would someone check for compatibility before a release is out? Modify their version number accordingly?
They'd need to compile against the new version anyway, wouldn't they?
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.
(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?
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.
Flags: blocking1.9.2? → blocking1.9.2-
Would it be sensible to add an extra pref controlling binary components?  Even a per-extension or per-Firefox-version pref?
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 422939
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.