Don't use the parent node options when creating new folder nodes, since they should retain
their original options.
Additionally, we can filter nodes in the queries rather than building a lot of nodes that
will be filtered out.
MozReview-Commit-ID: MmlGDe5QgV
Rather then trying to guess options from the parent or the root node, make query nodes directly
inherit some options from their parent.
MozReview-Commit-ID: 1YgDjrrMqGY
There's a heavy enough overhead to going through XPConnect for
every observer for every visit on the nsINavHistoryObserver
interface, so this patch reduces that by replacing the single-
visit notification with one which accepts an array of visits.
Some notes: To avoid problems with the orderings of the various
ways in which we notify about visits, we have to send our bulk
onVisits notification before doing any of the others. This does
mean it technically behaves slightly different than the prior
approach of interleaving the notifications, but I can't find any
way in which this has any consequences to the end result, and it
doesn't break any tests.
MozReview-Commit-ID: GdeooH8mCkg
Since `SetItemAnnotation` already queries `moz_bookmarks`, we can fetch
and pass the changed bookmark's info directly to
`nsNavBookmarks::NotifyItemChanged`, without going through the anno
observer.
This patch refactors the internal `Set*` methods to receive an optional
`BookmarkData` for item annotation changes, and fire `OnItemChanged`
notifications after notifying anno observers. `NotifyItemChanged` also
updates the bookmark's last modified time if requested.
MozReview-Commit-ID: Hz5qiOmAjsD
Since `SetItemAnnotation` already queries `moz_bookmarks`, we can fetch
and pass the changed bookmark's info directly to
`nsNavBookmarks::NotifyItemChanged`, without going through the anno
observer.
This patch refactors the internal `Set*` methods to pass an optional
`BookmarkData` from `SetItemAnnotation`, and fire `OnItemChanged`
notifications after notifying anno observers. `NotifyItemChanged` also
updates the bookmark's last modified time if requested.
MozReview-Commit-ID: Hz5qiOmAjsD
Also remove IsBookmarkedInDatabase(), mItemCount, RecursiveFindRedirectedBookmark(), UpdateKeywordsForRemovedBookmark() from nsNavBookmarks as they aren't used anywhere.
MozReview-Commit-ID: 4cZXAdRuVoF
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
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
Most consumers of `GetBookmarkIdsForURI` already don't need tags, the only
consumer which does (`TaggingService`) has been changed to use a separate
database query.
MozReview-Commit-ID: LabjaA6Q0GF
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
Due to the asynchronous behavior of history, it's possible a race condition
causes a page to be used when it was about to be removed.
For example a bookmark to a page could be added between the point where we
decide the page is an orphan, and the point where we actually remove the page.
Notifications in such a case may be improperly ordered, and there is no cheap
way to guarantee we won't notify a removal in such a case.
Since applicable solutions would be too expensive (code and perf wise), for now
just remove the assertion we can't satisfy, and protect removals from possibly
creating unexpected orphans.
Testing this would require a special setup where we can guarantee thread
scheduling order, so for now this comes without a test. Regardless it's
basically only adding safety guards.
MozReview-Commit-ID: KYkaqAv8fCB
