Closed Bug 255619 Opened 20 years ago Closed 19 years ago

Ability to restrict to compatible operating systems

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla1.8final

People

(Reporter: Bugzilla-alanjstrBugs, Assigned: jens.b)

References

Details

Attachments

(4 obsolete files)

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:
Blocks: 255622
Severity: normal → major
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.  
Flags: blocking-aviary1.0mac?
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.  
Depends on: 271250
Blocks: 271250
No longer depends on: 271250
Flags: blocking-aviary1.0mac?
Depends on: 272046
(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.
Assignee: bugs → jens.b
Depends on: 253742
Target Milestone: --- → Firefox1.1
Bug 253742 will not use a metadata approach, after all => no longer a
dependency, this one can be tackled independently.
No longer depends on: 253742
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).
Attachment #184625 - Flags: review?(benjamin)
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.
Attachment #184625 - Flags: review?(benjamin) → review-
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.
Attachment #184625 - Attachment is obsolete: true
Attachment #184793 - Flags: review?(benjamin)
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
Attachment #184793 - Flags: review?(benjamin) → review+
Fixes the #else nit (and adds me to the contributor list). Carrying over
bsmedberg's review and requesting approval.
Attachment #184793 - Attachment is obsolete: true
Attachment #185051 - Flags: review+
Attachment #185051 - Flags: approval-aviary1.1a2?
Attachment #185051 - Flags: approval-aviary1.1a2? → approval-aviary1.1a2+
Changing TARGET_ABI to TARGET_XPCOM_ABI to match bug 294835. Still r=bsmedberg
a=asa; ready for checkin.
Attachment #185051 - Attachment is obsolete: true
Checked in on trunk for 1.1a2.

Docs will follow on Devmo.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
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
Attachment #185600 - Attachment is obsolete: true
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
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.