зеркало из https://github.com/mozilla/gecko-dev.git
295 строки
15 KiB
ReStructuredText
295 строки
15 KiB
ReStructuredText
Gecko
|
||
=====
|
||
|
||
Gecko is Mozilla's rendering engine for the web. It is made up of HTML parsing and rendering,
|
||
networking, JavaScript, IPC, DOM, OS widget abstractions and much much more. It also includes some
|
||
UI components that are shared with applications built on top of Gecko such as Firefox for Desktop,
|
||
Firefox for Android, and Thunderbird. As well as rendering web pages Gecko is also responsible for
|
||
rendering the application's UI in some applications.
|
||
|
||
Networking (necko)
|
||
------------------
|
||
|
||
The networking engine services requests for DNS queries as well as for content hosted on web servers
|
||
using either http, http/2 or http/3 protocols to retrieve it. Necko uses NSS
|
||
(`Network Security Services library <https://wiki.mozilla.org/NSS>`_) for its cryptographic uses
|
||
e.g. to perform secure requests using TLS.
|
||
|
||
:ref:`Read more <Networking>`
|
||
|
||
JavaScript (SpiderMonkey)
|
||
-------------------------
|
||
|
||
The JavaScript engine is responsible for running JavaScript code both in content processes for
|
||
webpages as well as the JavaScript code that makes up the bulk of the UI in applications like
|
||
Firefox and Thunderbird.
|
||
|
||
:ref:`Read more <SpiderMonkey>`
|
||
|
||
JavaScript modules
|
||
##################
|
||
|
||
SpiderMonkey supports a proprietary type of JavaScript modules that was developed before the
|
||
EcmaScript module standard and even before commonjs was popular. These modules define exports using
|
||
an EXPORTED_SYMBOLS array containing a list of symbol names to be exported. This kind of module is
|
||
being replaced with standard EcmaScript modules.
|
||
|
||
XPCOM
|
||
-----
|
||
|
||
XPCOM (Cross-Platform Component Object Model) is Mozilla's version of Microsoft's
|
||
`COM <https://en.wikipedia.org/wiki/Component_Object_Model>`_.
|
||
|
||
XPCOM and :ref:`WebIDL <WebIDL>` are the primary ways for our frontend to communicate with the
|
||
underlying platform and to invoke methods that are implemented in native code.
|
||
|
||
XPCOM performs the following critical functions:
|
||
|
||
#. Allows creating software components with strictly defined
|
||
`interfaces <https://searchfox.org/mozilla-central/search?q=&path=.idl&case=false®exp=false>`_
|
||
using :ref:`XPIDL <XPIDL>`. These components can be implemented in C++, JavaScript or Rust. They
|
||
can also be invoked and manipulated in any of those languages regardless of the underlying
|
||
implementation language.
|
||
#. Acts as a process-global registry of named components (there are singleton "services" as well as
|
||
factories for creating instances of components).
|
||
#. Allows components and services to implement multiple interfaces, and to be dynamically cast to
|
||
those interfaces using ``QueryInterface``.
|
||
|
||
If that all sounds rather abstract, that's because it is. XPCOM is one of the oldest Mozilla
|
||
technologies that Firefox is still built on top of. XPCOM made a lot more sense in the late 90s when
|
||
Microsoft COM was still popular and the Mozilla codebase was also being developed as a general
|
||
application development platform for third-parties. There have been
|
||
`long-standing efforts <https://bugzilla.mozilla.org/show_bug.cgi?id=decom>`_ to move away from or
|
||
simplify XPCOM in places where its usefulness is questionable.
|
||
|
||
.. mermaid::
|
||
|
||
sequenceDiagram
|
||
Caller->>Component Registry: Get service @mozilla.org/cookie-banner-service#59;1
|
||
Component Registry->>nsCookieBannerService: new
|
||
nsCookieBannerService-->>Component Registry: return
|
||
Component Registry-->>Caller: return
|
||
Caller->>nsCookieBannerService: QueryInterface(nsICookieBannerService)
|
||
nsCookieBannerService-->>Caller: return
|
||
|
||
|
||
:ref:`Read more <XPCOM>`
|
||
|
||
Process Separation / Fission / IPC / Actors
|
||
-------------------------------------------
|
||
|
||
Firefox is a multi-process application. Over the lifetime of the main Firefox process, many other
|
||
sub processes can be started and stopped. A full catalogue of those different processes can be found
|
||
:ref:`here <Process Model>`.
|
||
|
||
Firefox communicates between these processes (mostly) asynchronously using the native inter-process
|
||
communication mechanisms of the underlying platform. Those mechanisms and their details are hidden
|
||
under cross-platform abstractions like :ref:`IPDL <IPDL: Inter-Thread and Inter-Process Message Passing>`
|
||
(for native code) and :ref:`JSActors <JSActors>` (for frontend code).
|
||
|
||
Firefox’s initial web content process separation (this was Project "Electrolysis", sometimes
|
||
shortened to “e10s”) shipped in 2016, and separated all web content into a single shared content
|
||
process. Not long after that, multiple content processes were enabled, and the web content of tabs
|
||
would be assigned to one of the created content processes using a round-robin scheme. In 2021, as
|
||
part of the mitigations for the `Spectre <https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)>`_
|
||
and `Meltdown <https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)>`_ processor
|
||
vulnerabilities, Firefox’s process model changed to enforce a model where each content process only
|
||
loads and executes instructions from a single site (this was Project “Fission”). You can read more
|
||
about the `underlying rationale and technical details about Project Fission <https://hacks.mozilla.org/2021/05/introducing-firefox-new-site-isolation-security-architecture/>`_.
|
||
|
||
DOM + WebIDL
|
||
------------
|
||
|
||
The :ref:`DOM APIs <DOM>` implement the functionality of elements in webpages and UI that is
|
||
rendered by Gecko.
|
||
|
||
:ref:`WebIDL <WebIDL>` is a standard specification for describing the interfaces to DOM objects. As
|
||
well as defining the interface for webpages Gecko also makes use of it for defining the interface to
|
||
various internal components. Like XPCOM, components that implement WebIDL interfaces can be called
|
||
from both C++ and JavaScript.
|
||
|
||
Style System (CSS)
|
||
------------------
|
||
|
||
The style system is responsible for parsing the document's CSS and using that to resolve a value for
|
||
every CSS property on every element in the document. This determines many characteristics of how
|
||
each element will render (e.g. fonts, colors, size, layout model).
|
||
|
||
:ref:`Read more <Layout & CSS>`
|
||
|
||
Layout
|
||
------
|
||
|
||
The layout engine is responsible for taking the DOM and styles and generating and updating a frame
|
||
tree ready for presentation to the user.
|
||
|
||
:ref:`Read more <Layout & CSS>`
|
||
|
||
Graphics
|
||
--------
|
||
|
||
The graphics component is responsible for taking the frame tree generated by the layout engine
|
||
and presenting it on screen.
|
||
|
||
:ref:`Read more <Graphics>`
|
||
|
||
Localization (Fluent)
|
||
---------------------
|
||
|
||
At Mozilla, localizations are managed by locale communities around the world, who are responsible
|
||
for maintaining high quality linguistic and cultural adaptation of Mozilla software into over 100
|
||
locales.
|
||
|
||
The exact process of localization management differs from project to project, but in the case of
|
||
Gecko applications, the localization is primarily done via a web localization system called
|
||
`Pontoon <https://pontoon.mozilla.org/>`_ and stored in HG repositories under
|
||
`hg.mozilla.org/l10n-central <https://hg.mozilla.org/l10n-central/>`_.
|
||
|
||
:ref:`Read more <Localization>`
|
||
|
||
Profiles
|
||
--------
|
||
|
||
A user profile is where Gecko stores settings, caches and any other data that must persist after the
|
||
application exits. It is made up of two directories on disk. The root directory (often just called
|
||
the profile directory) is where settings are stored. The local directory is for caches or any other
|
||
data that is temporary and will be rebuilt with no perceived loss to the user should it be
|
||
unavailable. These two directories can just be the same directory on disk. In an enterprise
|
||
environment or other situation where a user often switches between computers the root directory is
|
||
intended to be in a location on the network accessible to all computers while the local directory
|
||
can be local to the computer.
|
||
|
||
The profile service maintains a database of named user profiles that can be selected either from the
|
||
command line or through a basic user interface. Additionally command line arguments exist that will
|
||
run an application using any given directory for the user profile.
|
||
|
||
Preferences
|
||
-----------
|
||
|
||
The preferences service is a basic key value store for a user's settings. The keys are simple
|
||
strings and although are often considered to be hierarchical with parts separated by periods
|
||
internally everything is just held as flat lists. Preference values can be strings, integers or
|
||
boolean.
|
||
|
||
:ref:`Read more <libpref>`
|
||
|
||
Observer Service
|
||
----------------
|
||
|
||
The Observer Service (nsIObserverService) is a process-global XPCOM service that acts as a general
|
||
message bus implementing the `publish-subscribe pattern <https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern>`_.
|
||
Components implementing nsIObserver (or simple functions in JavaScript) can be registered with the
|
||
observer service to be notified when particular "topics" (topics are just developer-defined strings)
|
||
have occurred. This is particularly useful for creating a dependency between two components without
|
||
tightly coupling them.
|
||
|
||
For example, suppose there is a mechanism that clears a user's browsing history from the disk and
|
||
memory. At the end of that process, it might tell the observer service to notify on a topic like
|
||
"browser-clear-history". An observer registered for that topic might use that signal to know to
|
||
clear some of its caches, which might also contain browsing history.
|
||
|
||
Principals / Security model
|
||
---------------------------
|
||
|
||
Whenever Firefox on Desktop or Android fetches a resource from the web, Firefox performs a variety
|
||
of web security checks. Most prominently the `Same-origin Policy <https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy>`_
|
||
to ensure web pages can not harm end users by performing malicious actions, like e.g. accessing the
|
||
local file system. All web related security checks within Firefox are evaluated based on the
|
||
security concept of a Principal, which slightly simplified represents an origin. More precisely,
|
||
Firefox captures the security context using one of the following four types of Principals:
|
||
|
||
* Content-Principal, which reflects the Security Context of web content (origin). For example, when
|
||
visiting https://example.com a Content-Principal of https://example.com reflects the security
|
||
context of that origin and passes if scheme, host and port match.
|
||
* Null-Principal, which reflects a sandboxed (or least privilege) Security Context. For example,
|
||
when loading an iframe with a sandbox attribute Firefox internally generates a Null-Principal to
|
||
reflect that security context. A Null-Principal is only same-origin with itself.
|
||
* System-Principal, which reflects the security context of browser chrome-code and passes all
|
||
security checks. Important: Never use SystemPrincipal if the URI to be loaded can be influenced by
|
||
web content.
|
||
* Expanded-Principal, which is a list of principals to match the security needs for Content Scripts
|
||
in Firefox Extensions.
|
||
|
||
Whenever Firefox starts to load a resource (e.g. script, css, image) then security relevant meta
|
||
information including `nsIPrincipal <https://searchfox.org/mozilla-central/source/caps/nsIPrincipal.idl>`_
|
||
is attached to the `nsILoadInfo <https://searchfox.org/mozilla-central/source/netwerk/base/nsILoadInfo.idl>`_.
|
||
This load context providing object remains attached to the resource load (
|
||
`nsIChannel <https://searchfox.org/mozilla-central/source/netwerk/base/nsIChannel.idl>`_) throughout
|
||
the entire loading life cycle of a resource and allows Firefox to provide the same security
|
||
guarantees even if the resource load encounters a server side redirect.
|
||
|
||
Please find all the details about the Security Model of Firefox by reading the blog posts:
|
||
Understanding Web Security Checks in Firefox (
|
||
`Part 1 <https://blog.mozilla.org/attack-and-defense/2020/06/10/understanding-web-security-checks-in-firefox-part-1/>`_ &
|
||
`Part 2 <https://blog.mozilla.org/attack-and-defense/2020/08/05/understanding-web-security-checks-in-firefox-part-2/>`_)
|
||
and `Enforcing Content Security By Default within Firefox <https://blog.mozilla.org/security/2016/11/10/enforcing-content-security-by-default-within-firefox/>`_.
|
||
|
||
Chrome Protocol
|
||
---------------
|
||
|
||
The chrome protocol is an internal protocol used to reference files that ship as part of the
|
||
application. It is of the form ``chrome://<package>/<provider>/…`` where provider is one of content,
|
||
skin or locale. The majority of files referenced by the chrome protocol are stored in the omni.ja
|
||
files which are generated from :ref:`JAR manifest files <JAR Manifests>` at build time.
|
||
:ref:`Chrome manifest files <Chrome Registration>` are used to register where in the jar files
|
||
different packages are stored.
|
||
|
||
Resource Protocol
|
||
-----------------
|
||
|
||
The resource protocol is another internal protocol that can reference files that ship as part of the
|
||
application. Strictly speaking it is simply a mapped, all urls of the form ``resource://<package>/…``
|
||
are mapped to ``<new-uri>/…``. The mappings are generally defined using the resource instruction in
|
||
:ref:`chrome manifest files <chrome_manifest_resource>` however can also be defined at runtime and
|
||
some hardcoded mappings. Common examples include:
|
||
|
||
* ``resource://gre/…`` which references files in the gecko omni.ja file.
|
||
* ``resource://app/…``, often simplified as ``resource:///…`` which references files in the application
|
||
omni.ja file.
|
||
|
||
About pages/protocol
|
||
--------------------
|
||
|
||
The ``about`` protocol allows for binding short human-readable urls to internal content to be
|
||
displayed in the content area. For the most part each about page is simply a simpler name for
|
||
content in the chrome or resource protocols. For example the page ``about:processes`` simply loads
|
||
``chrome://global/content/aboutProcesses.html``. About pages are registered in the
|
||
`global <https://searchfox.org/mozilla-central/source/docshell/base/nsAboutRedirector.cpp>`_ and
|
||
`desktop <https://searchfox.org/mozilla-central/source/browser/components/about/AboutRedirector.cpp>`_
|
||
redirector components.
|
||
|
||
Toolkit
|
||
-------
|
||
|
||
Toolkit consists of components that can be shared across multiple applications built on top of
|
||
Gecko. For example, much of our WebExtensions API surfaces are implemented in toolkit, as several of
|
||
these APIs are shared between both Firefox, Firefox for Android, and in some cases Thunderbird.
|
||
|
||
:ref:`Read more <Toolkit>`
|
||
|
||
Linting / building / testing / developer workflow
|
||
-------------------------------------------------
|
||
|
||
Set-up the build environment using the :ref:`contributor's quick reference <Firefox Contributors' Quick Reference>`.
|
||
|
||
Make yourself aware of the :ref:`Linting set-up <Linting>`, in particular how to run
|
||
:ref:`linters and add hooks to automatically run the linters on commit <Running Linters Locally>`.
|
||
Additionally, make sure you set-up your editor with appropriate settings for linters. For VS Code,
|
||
these are set up automatically, as :ref:`per the documentation <Visual Studio Code>`.
|
||
|
||
For front-end work, ESLint and Prettier are the linters you'll use the most, see the
|
||
:ref:`section on ESLint <ESLint>` for details of both of those, which also has
|
||
:ref:`an FAQ <eslint_common_issues>`.
|
||
|
||
Details about :ref:`automated tests may be found here <Automated Testing>`. The most commonly used
|
||
tests are :ref:`XPCShell <XPCShell tests>` for testing backend components,
|
||
:ref:`Browser Chrome Tests <Browser chrome mochitests>` for testing the frontend UI and
|
||
:ref:`Web Platform Tests <web-platform-tests>` for testing web APIs.
|
||
|
||
WebExtensions
|
||
--------------
|
||
|
||
The WebExtensions APIs allow extensions to interact with the rest of the browser.
|
||
|
||
:ref:`Read more <WebExtensions API Development>`
|