505983 - add em:nativeComponentVersion to extension metadata, require for loading of binary components

Status: VERIFIED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[Mike Shaver (:shaver emeritus)]

I want to make extensions that use native components less fragile, as a precursor to my ultimate plan (shhh) of removing support for them entirely.  This bug is about the first part, which I would like to see in 1.9.2 so that we can give people JSctypes in 1.9.3 and then, well, let's not spoil the ending.

The intent is that:
- extensions which wish to use native components declare their intent specifically, along with micro-version information about what it's compatible with

- extensions with no nativeComponentVersion specified do not have native components loaded from their directory

- extensions with a mismatched nativeComponentVersion also do not have components loaded from their directory, but the rest of the extension still loads -- this will give them an opportunity to gracefully degrade, while not being all crashy-crashy

- we will, in the future this provides, be able to make small, backwards-compatible interface changes on stable branches as long as we preserve scripted compatibility -- the failure mode will be an error message telling the user what's out of date, not a startup or unpredictable crash.

<em:nativeComponentVersion> is a (set of? range of?) version number like the current one, but which we rev on the application side with every minor release that can affect native components (add-at-the-end interface changes, f.e.): 3.6, 3.6, 3.6, 3.6.4, 3.6.4, 3.6.6, etc..  We will need to figure out how to manage people just saying ".*", perhaps by not supporting it on this field?  AMO can probably help us make sure that people don't just fill it with 3.6, 3.6.1, ..., 3.6.25 and defeat the purpose. :-)

Comment 1

[Dave Townsend [:mossop]]

As far as I can tell the only benefit that this gives over the existing targetApplication system is that we only need to increment the binary version when necessary. The costs include confusion over version numbers, probably slow migration code during Firefox upgrade and quite substantial work to the update system (if we wanted to support remote updates to this for installed add-ons). I'm not really convinced that many extensions that need binary components are going to be able to do much with them unavailable either, not in the general case at least.

I'd like to propose an alternate solution that achieves nearly the same effect but with vastly less implementation required.

- extensions that use binary components cannot be forcibly enabled through the use of the extensions.checkCompatibility preference.

- extensions that wish to use binary components are not allowed to use the .* notation in the targetApplication maxVersion. It follows that without some kind of intervention their add-on will we disabled with every Firefox minor release.

I'll grant you it is a bit more heavy handed, but not a great deal I don't think. And we could explore avenues like giving AMO the right to increase an add-on's maxVersion from 3.6.0 to 3.6.1 when there are no binary changes in that minor release. It has the benefit though that the update system is already in place to propagate the changes and there is no costly migration code required.

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

It's not an issue of maxVersion -- the native binary version needs to match exactly, not be a range.  I don't think shaver's suggestion of "3.6.0, 3.6.1, 3.6.2" will work either; if so, we'd need to find a way to specify explicit binary components to load per version in the manifest.

> And we could explore avenues like giving AMO the right to increase an
> add-on's maxVersion from 3.6.0 to 3.6.1 when there are no binary changes in
> that minor release.

I don't think we have a good way of testing that there won't be any binary changes that won't impact extensions.  We're talking about changes that are more than just stuff like changing interfaces; I think we want to push the burden of native extension testing and compat maintenance on extension authors, not keep all that burden on us.

Comment 3

[Dave Townsend [:mossop]]

(In reply to comment #2)
> It's not an issue of maxVersion -- the native binary version needs to match
> exactly, not be a range.  I don't think shaver's suggestion of "3.6.0, 3.6.1,
> 3.6.2" will work either; if so, we'd need to find a way to specify explicit
> binary components to load per version in the manifest.

So if we want to only load binary components for an exact app version, and make it easy for a single extension to still support multiple versions in one package then I think tinkering in install.rdf isn't the way to go. A better choice (and dead easy to implement too) would be to support something along the same lines as the platform specific subdirectories (https://developer.mozilla.org/en/Bundles#Platform-specific_Subdirectories). Maybe an extension could place components in:

/platform/WINNT/1.9.1.1/components/mycomponent.dll
/platform/WINNT/1.9.1.2/components/mycomponent.dll
/platform/WINNT/1.9.1.3/components/mycomponent.dll

etc.

The version number relates to toolkit version, I think that would be the best option allowing the same bundle to be used in multiple applications.

Comment 4

[Benjamin Smedberg]

It's possible, even likely that the same DLL will in fact be compatible with multiple versions... requiring the author to ship the same DLL in multiple directories seems like bloat.

Not sure we can do this for 1.9.2, but I'd really like to start registering components in chrome.manifest... we could require binary components to be registered with explicit version numbers, e.g.:

binary-component path/to/mycomponent.dll versions=1.9.2,1.9.2.1...

Comment 5

[Dave Townsend [:mossop]]

(In reply to comment #4)
> It's possible, even likely that the same DLL will in fact be compatible with
> multiple versions... requiring the author to ship the same DLL in multiple
> directories seems like bloat.
> 
> Not sure we can do this for 1.9.2, but I'd really like to start registering
> components in chrome.manifest... we could require binary components to be
> registered with explicit version numbers, e.g.:
> 
> binary-component path/to/mycomponent.dll versions=1.9.2,1.9.2.1...

That seems good, or just use the existing version flags we have:

binary-component path/to/mycomponent.dll appversion=3.6.1
binary-component path/to/mycomponent.dll appversion=3.6.2
binary-component path/to/mycomponent.dll appversion=3.6.3

Slightly more long-winded for multiple versions, but it just uses mechanisms already in place without having to duplicate files.

Comment 6

[Benjamin Smedberg]

Sure, the important part is that a binary-component line would be required to have a version line.

Comment 7

[(not currently active) Ted Mielczarek]

Related: bug 422939

Comment 8

[Dave Townsend [:mossop]]

Seems like this is redundant now we have module versioning required for loading binary components.