This was automatically generated by the script modeline.py.
MozReview-Commit-ID: BgulzkGteAL
--HG--
extra : rebase_source : a4b9d16a4c06c4e85d7d85f485221b1e4ebdfede
Bug 1134923 removed the use of those functions in gecko, and left some
for the XPCOM standalone glue. The XPCOM standalone glue was severely
stripped down in bug 1306327, with the effect of removing the
implementation for those functions.
The remains in nsXPCOM.h are:
XPCOM_API(void*) NS_Alloc(size_t aSize);
XPCOM_API(void*) NS_Realloc(void* aPtr, size_t aSize);
XPCOM_API(void) NS_Free(void* aPtr);
With no implementation left, the first arm is never actually used, and
the second arm means every remaining use of those functions in the tree
is a macro expansion to one of moz_xmalloc, moz_xrealloc or free.
--HG--
extra : rebase_source : fd1669abc5a25d8edbd5c3a8522e22a5c3f558e2
This introduces filtering to avoid attempting to dispatch notifications
to WebExtensions processes and other types of content processes.
This is dependent upon bug 1395827 changing xpcshell to create its child
processes with a remote type of "web" in order to not break the push
xpcshell tests.
--HG--
extra : rebase_source : 347a9ed6997115a4b1fa362294efb7566b578ee6
extra : source : ebca24a97c779b0b66fa2261e8a771e7220e3cac
This introduces filtering to avoid attempting to dispatch notifications
to WebExtensions processes and other types of content processes.
--HG--
extra : source : ebca24a97c779b0b66fa2261e8a771e7220e3cac
This patch moves the decryption methods into a base `Decoder` class,
and an intermediate `OldSchemeDecoder` with subclasses for aesgcm and
aesgcm128. The base class provides a `decrypt` method that computes the
ECDH shared secret, derives the key and nonce, decrypts each record,
and removes padding. Subclasses implement `deriveKeyAndNonce`,
`unpadChunk`, `chunkSize`, and `padSize`.
MozReview-Commit-ID: IuGPaofWKNq
--HG--
extra : rebase_source : daaf414127a11525ce7d61c15b96e7f3493611de
This avoids creating a compartment in every content process that does
not use the push service.
MozReview-Commit-ID: HQxrVp9DxFd
--HG--
extra : rebase_source : 4920c118c3385b73edc61980d5582f6ba0e29221
This patch moves favicons blobs to a separate database names favicons.sqlite.
The dabatase is then ATTACHED to the main Places connection, so that its tables
can be used as if they were all part of the same database.
The favicons.database contains 3 tables:
1. moz_pages_w_icons
This is the way to join with moz_places, through page_url_hash and page_url.
We are not using the place id to avoid possible mismatches between places.sqlite
and favicons.sqlite. This way the database is "portable" and reusable even
if places.sqlite changes.
2. moz_icons
Contains icons payloads, each payload can either be an SVG or a PNG. These
are the only stored formats, any other format is rescaled and converted to
PNG. ICO files are split into single frames and stored as multiple PNGs.
SVG are distinguishable through width == UINT16_MAX
In future the table will also contain mask-icon color for SVG and average
color for PNGs.
The fixed_icon_url_hash is "fixed" to allow quickly fetch root icons, that
means icons like "domain/favicon.ico" that can also be reused for any page
under that domain.
3. moz_icons_to_pages
This is the relation table between icons and pages.
Each page can have multiple icons, each icon can be used by multiple pages.
There is a FOREIGN_KEY constraint between this (child) table and icons
or pages (parents), so that it's not possible to insert non-existing ids
in this table, and if an entry is removed from a parent table, the relation
will be automatically removed from here.
Note though that removing from the relation table won't remove from the
parent tables.
Since the relations are now many-many, it's no more possible to simply join
places with the icons table and obtain a single icon, thus it's suggested that
consumers go through the "page-icon" protocol.
The migration process from the old favicons table is async and interruptible,
it will be restarted along with the favicons service until the temp preference
places.favicons.convertPayloads is set to true.
MozReview-Commit-ID: CUCoL9smRyt
--HG--
extra : rebase_source : 4d25966596dcdf63c9c872425c5bf147406d25ac
We haven't found these probes useful for understanding the value of
Push, and many can be better determined from server metrics.
MozReview-Commit-ID: GM9K59OAbMT
--HG--
extra : rebase_source : b4478fe2aad5ce01ba5955406300973b3e0fb699
