Chrome 是应用程序内容窗口以外一系列用户接口元素。工具栏，如菜单栏，进度栏和标题栏这些都是chrome典型的元件。
A supplier of chrome for a given window type (e.g. for the browser window) is called a chrome provider. The providers work together to supply a complete set of chrome for a particular window, from the images on the toolbar buttons to the files that describe the text, content and appearance of the window itself.
There are three basic types of chrome providers:
The main source file for a window description comes from the content provider, and it can be any file type viewable from within Mozilla. It will typically be a XUL file, since XUL is designed for describing the contents of windows and dialogs. The JavaScript files that define the user interface are also contained within the content packages, as well as most XBL binding files.
Localizable applications keep all their localized information in locale providers. This allows translators to plug in a different chrome package to translate an application without altering the rest of the source code. The two main types of localizable files are DTD files and Java-style properties files.
A skin provider is responsible for providing a complete set of files that describe the visual appearance of the chrome. Typically a skin provider will provide CSS files and images.
Note: Scripts (including those found in XBL) loaded from skin packages will not execute.
The gecko runtime maintains a service known as the chrome registry that provides mappings from chrome package names to the physical location of chrome packages on disk.
This chrome registry is configurable and persistent, and thus a user can install different chrome providers, and select a preferred skin and locale. This is accomplished through xpinstall and the extension manager.
In order to inform the chrome registry of the available chrome, a text manifest is used: this manifest is "chrome.manifest" in the root of an extension, or theme, and chrome/*.manifest in a XULRunner application.
The plaintext chrome manifests are in a simple line-based format. Each line is parsed individually; if the line is parseable the chrome registry takes the action identified by that line; otherwise the chrome registry ignores that line (and prints a warning message in the runtime error console).
locale packagename localename path/to/files skin packagename skinname path/to/files
A line is a comment if it begins with the character '#'; any other characters on the line are ignored.
# this line is a comment - you can put whatever you want here
A content package is registered with the line
contentpackagenameuri/to/files/[flags]
This will register a location to use when resolving the URI chrome://packagename /content/.... The URI may be absolute or relative to the location of the manifest file. Note, that it must end with an '/'.
A locale package is registered with the line
localepackagenamelocalenameuri/to/files/[flags]
This will register a locale package when resolving the URI chrome://packagename /locale/... . Thelocalename is usually a plain language identifier "en" or a language-country identifier "en-US". If more than one locale is registered for a package, the chrome registry will select the best-fit locale using the user's preferences.
A skin package is registered with the line
skinpackagenameskinnameuri/to/files/[flags]
This will register a skin package when resolving the URI chrome://packagename/skin/... . Theskinname is an opaque string identifying an installed skin. If more than one skin is registered for a package, the chrome registry will select the best-fit skin using the user's preferences.
Style overlays (custom CSS which will be applied to a chrome page) are registered with the following syntax:
style chrome://URI-to-style chrome://stylesheet-URI[flags]
In some cases an extension or embedder may wish to override a chrome file provided by the application or XULRunner. In order to allow for this, the chrome registration manifest allows for "override" instructions:
override chrome://package/type/original-uri.whatevernew-resolved-URI[flags]
Note: overrides are not recursive (so overriding chrome://foo/content/bar/ with file:///home/john/blah/ will not usually do what you want or expect it to do).
There is a currently a bug in the Firefox 2.0.0.* series, as well as previous builds, where if you use a relative URL for thenew-resolved-URI parameter, the override will not work. You need to provide a fully qualified URL (ie, one that is resolvable anywhere, not just in the directory the chrome manifest resides in). Given that the extension or application developer usually is unable to predict what the full path to such a file might be, currently one would normally only use this directive using another chrome:// URL as thenew-resolved-URI parameter. See {{ Bug(323455) }}.
{{ Fx_minversion_inline(3) }}
When using JavaScript code modules it may be necessary to create resource protocol aliases so extensions and applications can load modules using Components.utils.import. Aliases can be created using the resource instruction:
resourcealiasnameuri/to/files/[flags]
This will create an mapping for the res://<aliasname>/ to the path given.
Note that there are no security restrictions preventing web content from including content at resource uris so take care with what you make visible there.
Manifest lines can have multiple, space-delimited flags added at the end of the registration line. These flags mark special attributes of chrome in that package, or limit the conditions under which the line is used.
Extensions may install into multiple applications. There may be chrome registration lines which only apply to one particular application. The flag
application=app-ID
indicates that the instruction should only be applied if the extension is installed into the application identified byapp-ID is running. Multiple application flags may be included on a single line, in which case the line is applied if any of the flags match.
Extensions may install into multiple versions of an application. There may be chrome registration lines which only apply to a particular application version. The flag
appversion=version appversion<version appversion<=version appversion>version appversion>=version
indicates that the instruction should only be applied if the extension is installed into the application version identified. Multiple appversion flags may be included on a single line, in which case the line is applied if any of the flags match. The version string must conform to the Toolkit version format.
Versions of Gecko before 1.8.0.13 and 1.8.1.5 contained a bug where if you use the comparisons <, > or = then the version string had be 2 characters or more long. If not you would get a message in the error console that the appversion flag was not recognized. See {{ Bug(380398) }}.
{{ Fx_minversion_inline(3) }} Untrusted content is no longer allowed to reference resources in chrome packages. If this needs to be explicitly allowed, set the contentaccessible flag to yes for behavior as found in older versions.
The contentaccessible flag applies only to content packages: it is not recognized for locale or skin registration. However, the matching locale and skin packages will also be exposed to content. Changed for Firefox 3 RC 1 for {{ bug(292789) }}.
{{ Fx_minversion_inline(3) }} Extensions (or themes) may offer different features depending on the operating system on which Firefox is running. The value is compared to the value of OS_TARGET for the platform.
os=WINNT os=Darwin
See OS_TARGET for a more complete list of os names. The os name is case insensitive.
{{ Fx_minversion_inline(3) }} An extension or theme may need to operate differently depending on which version of an operating system is running. For example, a theme may wish to adopt a different look on Mac OS X 10.5 than 10.4:
osversion>=10.5
Some packages are marked with a special flag indicating that they are platform specific. Some parts of content, skin, locales may be different based on the platform being run. These packages contain three different sets of files, for Windows and OS/2, Macintosh, and Unix-like platforms. For example, the order of the "OK" and "Cancel" buttons in a dialog is different, as well as the names of some items.
The "platform" modifier is only parsed for content registration, it is not recognized for locale or skin registration. However it applies to content, locale, and skin parts of the package, when specified.
To indicate that a package is platform-specific, add the "platform" modifier to the "content" line after the path, for example:
content global-platform jar:toolkit.jar!/toolkit/content/global-platform/ platform
Once that is specified in your manifest you then ensure that under the directory global-platform are subdirectories win (Windows/OS2), mac (OS9/OSX), or unix (Everything Else). Anything residing outside of these subdirectories will be ignored.
Chrome packages can decide whether to use the xpcnativewrappers security mechanism to protect their code against malicious content that they might access. See Safely accessing content DOM from chrome for details.
As of Firefox 1.5 alpha releases (Deer Park alphas), this flag is *off* by default, and must be explicitly enabled by specifying xpcnativewrappers=yes.
As of the first Firefox 1.5 beta release, this flag will be enabled by default, and extensions that need insecure access to the content objects will be required to specify xpcnativewrappers=no.
The xpcnativewrappers flag applies only to content packages: it is not recognized for locale or skin registration.
content necko jar:comm.jar!/content/necko/ xpcnativewrappers=yes locale necko en-US jar:en-US.jar!/locale/en-US/necko/ content xbl-marquee jar:comm.jar!/content/xbl-marquee/ content pipnss jar:pipnss.jar!/content/pipnss/ locale pipnss en-US jar:en-US.jar!/locale/en-US/pipnss/ # Firefox-only overlay chrome://browser/content/pageInfo.xul chrome://pippki/content/PageInfoOverlay.xul application={ec8030f7-c20a-464f-9b0e-13a3a9e97384} overlay chrome://communicator/content/pref/preftree.xul chrome://pippki/content/PrefOverlay.xul overlay chrome://navigator/content/pageInfo.xul chrome://pippki/content/PageInfoOverlay.xul application=seamonkey@applications.mozilla.org content pippki jar:pippki.jar!/content/pippki/ xpcnativewrappers=yes locale pippki en-US jar:en-US.jar!/locale/en-US/pippki/ content global-platform jar:toolkit.jar!/content/global-platform/ platform skin global classic/1.0 jar:classic.jar!/skin/classic/global/ override chrome://global/content/netError.xhtml jar:embedder.jar!/global/content/netError.xhtml content inspector jar:inspector.jar!/content/inspector/ xpcnativewrappers=no
The Chrome List extension shows all registered chrome. This is very helpful when trying to write a chrome.manifest file as you can inspect where the files are being mapped from (jar files, local directory, etc.)
Before the plaintext manifests were introduced (which happened in Firefox 1.5, Toolkit 1.8), RDF manifests named "contents.rdf" were used to register chrome. This format is deprecated; however, the Mozilla Suite (SeaMonkey) does not support the plaintext manifest format yet, so contents.rdf manifests are required for extensions that wish to maintain backwards compatibility with Firefox 1.0 or the suite.
{{ page("zh-CN/docs/Toolkit_API/Official_References") }}