User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.1+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.1+ Not every xpi is cross-platform. Mozilla Calendar is an example. You should be able to specify in install.rdf which operating systems it works with. This would also be helpful to prevent installing OSX themes on Windows and vice versa. Perhaps this should be available as an optional whitelist and an optional blacklist. Reproducible: Always Steps to Reproduce:

If we do a whitelist, do we want to go with GUIDs? minVer and maxVers? For example, if we want to restrict which versions of OSX something is compatible with.

well as far as whitelist goes, I would say (as should be apparant) we would need to ensure that if no OS is listed it will be available to all (keep it as simple as possible for the most people). A blacklist is not possible due to the shear number of OS's. I also agree we need to _allow_ minVer and maxVer, The only problem is, how will we define minVer and maxVer to each OS, Windows API for example uses very different Version numbering than is apparant to the user (the version is only apparant in programming for the most part), and how to distinguish in windows for example, IE version (since IE 6 on win 98 has more programming features avail than windows has with IE 5 and win98) As a minority, using OS version is definately a must, versioning would be very helpful though due to the complexity of implimentation it is not as high up on my personal wish-list.

This causes an XBL Binding error when someone picks the wrong one.

Previous comment was related to bug 222654

We'll need GUIDs, and an update to the web service call for this. We could establish the current OS's GUID with ifdefs at build time. Then we wouldn't have to rely on useragent detection.

(In reply to comment #5) > We'll need GUIDs, and an update to the web service call for this. We could > establish the current OS's GUID with ifdefs at build time. Then we wouldn't > have to rely on useragent detection. Wouldn't the os/architecture strings (__OSARCH__ as used in bug 272046) be sufficient here? IIRC, navigator.platform is the same value, e.g. "Win32". I'd say they form a de-facto-standard inside mozilla and are easier to compare to the current OSARCH. Using GUIDs here would mean introducing new constants, new #ifdefs etc. to the build process, which sounds like overkill.

Yes, I gave up on the idea of using GUIDs. This is to strengthen bug 272046. We should use __OSARCH__ as a const, not navigator, since we don't want this overrided.

Once bug 253742 is checked in, I'll extend the em:platform nodes it introduces, so they can be added globally to theme/extension install.rdf to form a whitelist. As they are using regular expressions, it might be possible to do some OS-version-detection (e.g. all Windows versions can be distinguished, don't know for Mac OS) - but even if it isn't, this will still be better than nothing.

Bug 253742 will not use a metadata approach, after all => no longer a dependency, this one can be tackled independently.

The benefit of metadata is that it can be parsed by UMO when the XPI is uploaded.

(In reply to comment #10) > The benefit of metadata is that it can be parsed by UMO when the XPI is > uploaded. Sure, that's why *this* bug will use metadata. In contrast, declarations which library should be loaded on which platform are not that interesting to UMO - and that's exactly what bug 253742 is about. For the record: this bug will allow to declare "FooExt 0.7 works on Windows and Linux" so it's rejected by a Macintosh Firefox, and bug 253742 will allow Firefox to only load the FooExtComponent.dll on Windows, but the FooExtComponent.so on Linux.

This patch lets the EM check for <em:targetPlatform> nodes in install.rdf - if there are any, one of them has to match OS_TARGET - otherwise, an error message is displayed and the package rejected. Also changes the value transmitted to the update server from OS_ARCH (platform compiled on) to OS_TARGET (platform compiled for).

Comment on attachment 184625 [details] [diff] [review] introduce <em:targetPlatform> nodes to install.rdf I *think* that you need a try/catch around "var targetPlatforms = installManifest.GetTargets...". I'm not sure about this though. I think we should do both TARGET_OS and TARGET_OS_ABI here, to match the platform dirs.

This adds try/catch around the installManifest.GetTargets call, and the ability to define compatible ABIs: <em:targetPlatform>Linux_gcc2</em:targetPlatform> <em:targetPlatform>Linux_gcc3</em:targetPlatform> <em:targetPlatform>WINNT_msvc</em:targetPlatform> <em:targetPlatform>OS2</em:targetPlatform> When an ABI string is detected for our own platform, it is assumed that ABI compatibility is required. Even if we don't know that other ABI, or we don't know our own, the package is rejected. Platform arcs with and without platform can be mixed, with one exception: adding a bare "WINNT" to the above will gain you nothing, as the msvc variant will block all other ABIs anyway.

Any comments on the wording? It used to say "operating system" in the first patch, but as it now applies to ABI, too, it has to be more generic. I think the wording below is not too techy, but still gives the user information the extension author needs. "FooExt" could not be installed because it is not compatible with your Firefox build type (WINNT_msvc). Please contact the author of this item about the problem. ("Firefox" is of course not hard-coded here)

Comment on attachment 184793 [details] [diff] [review] introduce <em:targetPlatform> nodes to install.rdf, v2 instead of #ifdef TARGET_ABI ... #endif #ifndef TARGET_ABI ... #endif just use #ifdef ... #else ... #endif

Fixes the #else nit (and adds me to the contributor list). Carrying over bsmedberg's review and requesting approval.

Changing TARGET_ABI to TARGET_XPCOM_ABI to match bug 294835. Still r=bsmedberg a=asa; ready for checkin.

Checked in on trunk for 1.1a2. Docs will follow on Devmo.

Comment on attachment 185600 [details] [diff] [review] introduce <em:targetPlatform> nodes to install.rdf, v4 mozilla/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.properties 1.11 mozilla/toolkit/mozapps/extensions/src/Makefile.in 1.5 mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in 1.114

Are the docs up yet?

(In reply to comment #21) > Are the docs up yet? No, as I'm still waiting for the install.rdf spec to be added to DevMo. Either bsmedberg will incorporate the em:targetPlatform syntax while writing it, or I'll add it afterwards.

*** Bug 254475 has been marked as a duplicate of this bug. ***

wow! there a reason why this hasn't been marked as verified yet? *** VERIFIED - PLEASE MARK Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3 ID:2008020514 -Mike