There are surprisingly many of them.
(Plus a couple of unnecessary checks after `new` calls that were nearby.)
--HG--
extra : rebase_source : 47b6d5d7c5c99b1b50b396daf7a3b67abfd74fc1
NullPrincipal::Create() (will null OA) may cause an OriginAttributes bypass.
We change Create() so OriginAttributes is no longer optional, and rename
Create() with no arguments to make it more explicit about what the caller is doing.
MozReview-Commit-ID: 7DQGlgh1tgJ
This patch covers two cases when loading a favicon:
1. Get the request context ID of the document load group, when <link rel="icon"> is found in the page.
2. Use the top level document's request context ID when using the default favicon.
Makes initing Places services cheaper, by delaying the connection creation to the first time
it's actually needed.
Same way, delays reading the bookmark roots at the first time they are requested.
Deprecates the concept of lazy observers, since they are no more needed, we can just use addObserver.
Simplifies the startup path: always sends "places-init-complete" (both as a category and a topic) when
the connection starts and adds a "locked" database state when we can't get a working connection.
Makes PlacesCategoriesStarter register for the new category, since it's cheaper than being a bookmarks
observer.
Fixes a couple race conditions in keywords and expiration due to new startup timings.
Removes a test in test_keywords.js that is no more easily feasible, since it'd requires a pre-build
places.sqlite that should be kept up-to-date at every version.
MozReview-Commit-ID: 6ccPUZ651m0
--HG--
extra : rebase_source : 07376076eb42c84caaedeffd75f133d83a6c3d70
The initially guessed limit for favicons is too small, some common favicons are bigger, so this increases it.
Additionally, if an icon is larger than the limit, instead of discarding it we can rescale it down until it fits.
MozReview-Commit-ID: BaijUP9oDMQ
--HG--
extra : rebase_source : 82d4a94ecc68d5185bfd6665184290d5226b85f6
Root domain icons are no more associated with their pages, BUT if the page uses
a root domain icon from another domain, it should still get an association with it
or we couldn't relate the two.
This also fixes an overlooked problem in PlacesTestUtils where Date objects
cross a boundary and fail instanceof checks. This causes failures in the same
test that this patch is modifying.
To protect from future similar issues some protection has been added to updatedPlaces
so that it will crash in debug builds.
MozReview-Commit-ID: 3MTKhGj3ehj
--HG--
extra : rebase_source : 55120252e7ea8abb91f21ca2486deddc43795142
Root domain icons are no more associated with their pages, BUT if the page uses
a root domain icon from another domain, it should still get an association with it
or we couldn't relate the two.
This also fixes an overlooked problem in PlacesTestUtils where Date objects
cross a boundary and fail instanceof checks. This causes failures in the same
test that this patch is modifying.
To protect from future similar issues some protection has been added to updatedPlaces
so that it will crash in debug builds.
MozReview-Commit-ID: 3MTKhGj3ehj
--HG--
extra : rebase_source : e36ba1ab41649927f92fee053c10bf43474a0bcf
Remove page-icon entries when the icon changes, so that we start showing the
new content.
Also adds an SVG page-icon test.
MozReview-Commit-ID: 10MIOvwbQ20
--HG--
extra : rebase_source : 27775ada780c0c949555d5bed979e57227549bc1
Root domain icons should be retained as far as possible, and only expired when
a domain is removed from the database. We do that through the moz_hosts trigger.
Additionally, since we return root domain icons without the need for a direct
association, we can save a lot of database space and performance by not storing
associations at all for root domain icons.
This has some downsides, since we don't exactly know if the page was really
associated with that root icon or not, but the perf gains are far superior.
Note that we still create associations during migration, since it would be too
expensive to examine every single url to figure out if it's a root domain icon.
MozReview-Commit-ID: 3mlfcOV8ixC
--HG--
extra : rebase_source : 789300afb5d700095bd83aabf1a37200218ff210
When optimizing an ico file, split it into its single resources and pick only
the sizes we care about. This also de-dupes same size resources.
The migration path doesn't split ico files, since it's a performance hot path
and we should try to reduce the I/O load at that time. The worst case is that
some icons may not look that much crisp until the next page reload.
Note that while the "resource" naming would be more appropriate for ico files,
compared to "frame" that is more appropriate for animations, the patch still
uses the frame name, cause it's far less generic and can be more easily
associated with the concept of a graphical asset. Regardless, it's not exposed
in any public API.
MozReview-Commit-ID: 3vrGXzJDfjX
--HG--
extra : rebase_source : d3015836abd5f7737cab42a3b102b5d718c692d6
When an icon for a specific page is not available, try to fallback for the root
domain icon.
This is valid for both getFaviconUrlForPage and getFaviconDataforPage, as well
as the page-icon: protocol.
MozReview-Commit-ID: JC4cx1PAY38
--HG--
extra : rebase_source : f50e0d4d0ab71a0b218c3d7caaa0da149838d148
Both page-icon: and moz-anno:favicon: should support a simple #size=NNN ref
fragment to allow consumers to request a specific sized icon (if available).
The service will do its best to satisfy the request, but it's not guaranteed.
If no size hint is found, it will default to the biggest icon payload available.
It's currently not possible to test the fragment on moz-anno:favicon: since that
requires imagelib support to extract payloads from ico files. Thus a test will
be added at a later time.
MozReview-Commit-ID: G221MKY7rfs
--HG--
extra : rebase_source : 029a6fcaa9dadda24f8d3ebc9b36c1a0ec6314c6
Updates consumers to the new behavior.
Some consumers are changed to use the "page-icon:" protocol, since it's not
trivial to join the icons table and get a single result out of it. In most cases
the join would return multiple results since a page can have multiple icon payloads.
These consumers for now will return the biggest payload, bug 1347532 will fix
some of them to properly pass a #size=NN fragment.
Note that, even before, these were just "moz-anno:favicon:" uris, and the
payload had to be fetched from the database.
Some other consumers for now just fallback to the largest payload, by passing 0
to GetFaviconURLForPage.
The favicon optimization still happens on the main-thread, bug 1346139 will
handle that problem.
Most of the changes involve handling the modified IconData objects, that now
retain an array of payloads, rather than just one. But note that .ico files are
not yet split into single frames, due to imagelib missing APIs that will be handled
in bug 1337402.
The other changes involve fixing queries to properly join with the new tables.
Finally, note that thanks to the FOREIGN KEYS support, removing from moz_icons or
moz_pages_w_icons will also remove relations from moz_icons_to_pages.
The system only supports square icons, so icons are resized based on their larger side.
This doesn't include new tests, those will be in a following changeset.
MozReview-Commit-ID: JUkpquhpS8y
--HG--
rename : toolkit/components/places/tests/unit/test_svg_favicon.js => toolkit/components/places/tests/favicons/test_svg_favicon.js
extra : rebase_source : fa49c4a81d6ab6b34a2f19ee4175e889a6e9d734
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
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
