This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
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
`createCodebasePrincipalFromOrigin` mangles the origin after extracting
the suffix. The proper long-term fix is to serialize and store the
original principal, instead of reconstructing a new codebase principal
from the scope and origin suffix.
MozReview-Commit-ID: bS2lRx3n7j
--HG--
extra : rebase_source : b62001f997718455b2b6c7cb3074ee79fa68ec25
CLOSED TREE
Backed out changeset 204a1746f421 (bug 1210211)
Backed out changeset e5d16111e809 (bug 1210211)
Backed out changeset b78d00c9af42 (bug 1210211)