Bug 2038819 - Convert docs/overview RST documentation to Markdown r=firefox-source-docs-reviewers,ahal
Differential Revision: https://phabricator.services.mozilla.com/D304211
This commit is contained in:
Sylvestre Ledru
committed by
sledru@mozilla.com
sledru@mozilla.com
parent
efd79b759c
commit
c7c85d72ce
@@ -1,5 +1,4 @@
|
||||
Gecko
|
||||
=====
|
||||
# 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
|
||||
@@ -7,134 +6,123 @@ UI components that are shared with applications built on top of Gecko such as Fi
|
||||
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)
|
||||
------------------
|
||||
## 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
|
||||
([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>`
|
||||
{ref}`Read more <networking>`
|
||||
|
||||
JavaScript (SpiderMonkey)
|
||||
-------------------------
|
||||
## 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>`
|
||||
{ref}`Read more <spidermonkey>`
|
||||
|
||||
System Modules
|
||||
--------------
|
||||
## System Modules
|
||||
|
||||
Gecko uses a variant of the standard ECMAScript module to implement the browser
|
||||
internal.
|
||||
|
||||
:ref:`Read more <System Modules>`
|
||||
{ref}`Read more <System Modules>`
|
||||
|
||||
XPCOM
|
||||
-----
|
||||
## XPCOM
|
||||
|
||||
XPCOM (Cross-Platform Component Object Model) is Mozilla's version of Microsoft's
|
||||
`COM <https://en.wikipedia.org/wiki/Component_Object_Model>`_.
|
||||
[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
|
||||
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
|
||||
1. 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
|
||||
2. 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``.
|
||||
3. 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
|
||||
[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::
|
||||
```{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
|
||||
```
|
||||
|
||||
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>`
|
||||
|
||||
|
||||
:ref:`Read more <XPCOM>`
|
||||
|
||||
Process Separation / Fission / IPC / Actors
|
||||
-------------------------------------------
|
||||
## 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>`.
|
||||
{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).
|
||||
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
|
||||
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/>`_.
|
||||
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
|
||||
------------
|
||||
## DOM + WebIDL
|
||||
|
||||
The :ref:`DOM APIs <DOM>` implement the functionality of elements in webpages and UI that is
|
||||
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
|
||||
{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)
|
||||
------------------
|
||||
## 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
|
||||
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 <Style system (CSS) & Layout>`
|
||||
{ref}`Read more <Style system (CSS) & Layout>`
|
||||
|
||||
Layout
|
||||
------
|
||||
## 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 <Style system (CSS) & Layout>`
|
||||
{ref}`Read more <Style system (CSS) & Layout>`
|
||||
|
||||
Graphics
|
||||
--------
|
||||
## 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>`
|
||||
{ref}`Read more <graphics>`
|
||||
|
||||
Localization (Fluent)
|
||||
---------------------
|
||||
## 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
|
||||
@@ -142,13 +130,12 @@ 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 a GitHub repository under
|
||||
`github.com/mozilla-l10n/firefox-l10n <https://github.com/mozilla-l10n/firefox-l10n>`_.
|
||||
[Pontoon](https://pontoon.mozilla.org/) and stored in a GitHub repository under
|
||||
[github.com/mozilla-l10n/firefox-l10n](https://github.com/mozilla-l10n/firefox-l10n).
|
||||
|
||||
:ref:`Read more <Localization>`
|
||||
{ref}`Read more <localization>`
|
||||
|
||||
Profiles
|
||||
--------
|
||||
## 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
|
||||
@@ -163,21 +150,19 @@ The profile service maintains a database of named user profiles that can be sele
|
||||
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
|
||||
-----------
|
||||
## 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>`
|
||||
{ref}`Read more <libpref>`
|
||||
|
||||
Observer Service
|
||||
----------------
|
||||
## 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>`_.
|
||||
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
|
||||
@@ -188,107 +173,100 @@ memory. At the end of that process, it might tell the observer service to notify
|
||||
"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
|
||||
---------------------------
|
||||
## 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>`_
|
||||
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
|
||||
- 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,
|
||||
- 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
|
||||
- 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
|
||||
- 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 :searchfox:`nsIPrincipal <caps/nsIPrincipal.idl>`
|
||||
is attached to the :searchfox:`nsILoadInfo <netwerk/base/nsILoadInfo.idl>`.
|
||||
information including {searchfox}`nsIPrincipal <caps/nsIPrincipal.idl>`
|
||||
is attached to the {searchfox}`nsILoadInfo <netwerk/base/nsILoadInfo.idl>`.
|
||||
This load context providing object remains attached to the resource load (
|
||||
:searchfox:`nsIChannel <netwerk/base/nsIChannel.idl>`) throughout
|
||||
{searchfox}`nsIChannel <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/>`_.
|
||||
[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
|
||||
---------------
|
||||
## 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,
|
||||
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
|
||||
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
|
||||
-----------------
|
||||
## 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
|
||||
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
|
||||
- `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
|
||||
--------------------
|
||||
## About pages/protocol
|
||||
|
||||
The ``about`` protocol allows for binding short human-readable urls to internal content to be
|
||||
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
|
||||
:searchfox:`global <docshell/base/nsAboutRedirector.cpp>` and
|
||||
:searchfox:`desktop <browser/components/about/AboutRedirector.cpp>`
|
||||
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
|
||||
{searchfox}`global <docshell/base/nsAboutRedirector.cpp>` and
|
||||
{searchfox}`desktop <browser/components/about/AboutRedirector.cpp>`
|
||||
redirector components.
|
||||
|
||||
Toolkit
|
||||
-------
|
||||
## 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>`
|
||||
{ref}`Read more <toolkit>`
|
||||
|
||||
Linting / building / testing / developer workflow
|
||||
-------------------------------------------------
|
||||
## Linting / building / testing / developer workflow
|
||||
|
||||
Set-up the build environment using the :ref:`contributor's quick reference <Firefox Contributors' Quick Reference>`.
|
||||
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>`.
|
||||
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>`.
|
||||
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>`.
|
||||
{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.
|
||||
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
|
||||
--------------
|
||||
## WebExtensions
|
||||
|
||||
The WebExtensions APIs allow extensions to interact with the rest of the browser.
|
||||
|
||||
:ref:`Read more <WebExtensions API Development>`
|
||||
{ref}`Read more <WebExtensions API Development>`
|
||||
@@ -0,0 +1,8 @@
|
||||
# A Quick Guide to Mozilla Applications
|
||||
|
||||
```{toctree}
|
||||
gecko
|
||||
/browser/overview
|
||||
/mobile/android/index
|
||||
ios
|
||||
```
|
||||
@@ -1,9 +0,0 @@
|
||||
A Quick Guide to Mozilla Applications
|
||||
=====================================
|
||||
|
||||
.. toctree::
|
||||
|
||||
gecko
|
||||
/browser/overview
|
||||
/mobile/android/index
|
||||
ios
|
||||
@@ -0,0 +1,23 @@
|
||||
# Firefox for iOS
|
||||
|
||||
Firefox iOS is built natively for iOS, and doesn\`t use Gecko.
|
||||
|
||||
Due to Apple\`s restrictions for browsers on iOS, WKWebKit is how users will interact with the web,
|
||||
and how developers interact with web elements. The chrome around WKWebKit, however, is built in
|
||||
Swift. UI wise, it is a combination of UIKit and SwiftUI; due to supporting n-2 iOS versions, the
|
||||
team is limited from moving over to SwiftUI fully.
|
||||
|
||||
Firefox uses several external Mozilla packages, namely:
|
||||
|
||||
- Mozilla Rust Components for various Rust based application components such as FXAClient, Nimbus, etc.
|
||||
- Glean SDK for telemetry
|
||||
- Telemetry (deprecated; not actively used, but not fully removed yet)
|
||||
|
||||
Documentation can be found in the project [wiki](https://github.com/mozilla-mobile/firefox-ios/wiki).
|
||||
|
||||
## WKWebView
|
||||
|
||||
WKWebView is part of Apple\`s WebKit framework. It supports a complete web browsing experience,
|
||||
rendering HTML, CSS, and JavaScript content alongside an app\`s native views. It can also be thought
|
||||
of as an API to help render web pages on Apple platforms. For more information on WKWebView itself,
|
||||
please see [Apple's documentation](https://developer.apple.com/documentation/webkit/wkwebview).
|
||||
@@ -1,25 +0,0 @@
|
||||
Firefox for iOS
|
||||
===============
|
||||
|
||||
Firefox iOS is built natively for iOS, and doesn`t use Gecko.
|
||||
|
||||
Due to Apple`s restrictions for browsers on iOS, WKWebKit is how users will interact with the web,
|
||||
and how developers interact with web elements. The chrome around WKWebKit, however, is built in
|
||||
Swift. UI wise, it is a combination of UIKit and SwiftUI; due to supporting n-2 iOS versions, the
|
||||
team is limited from moving over to SwiftUI fully.
|
||||
|
||||
Firefox uses several external Mozilla packages, namely:
|
||||
|
||||
* Mozilla Rust Components for various Rust based application components such as FXAClient, Nimbus, etc.
|
||||
* Glean SDK for telemetry
|
||||
* Telemetry (deprecated; not actively used, but not fully removed yet)
|
||||
|
||||
Documentation can be found in the project `wiki <https://github.com/mozilla-mobile/firefox-ios/wiki>`_.
|
||||
|
||||
WKWebView
|
||||
---------
|
||||
|
||||
WKWebView is part of Apple`s WebKit framework. It supports a complete web browsing experience,
|
||||
rendering HTML, CSS, and JavaScript content alongside an app`s native views. It can also be thought
|
||||
of as an API to help render web pages on Apple platforms. For more information on WKWebView itself,
|
||||
please see `Apple's documentation <https://developer.apple.com/documentation/webkit/wkwebview>`_.
|
||||
Reference in New Issue
Block a user