This moves AboutNewTab.init from nsBrowserGlue.js handling of "browser-delayed-startup-finished" into aboutNewTabService.js so that when the service is loaded once from the main thread probably by browser.js towards the beginning of _delayedStartup just before potentially calling gBrowser.loadTabs, the service triggers the attaching of RemotePages(about:newtab) before any about:newtab pages load.
Additionally even when RemotePages starts early enough, Activity Stream might not borrow the RemotePages instance early enough to catch the RemotePage:Load message, so to simulate that, RemotePages now remembers when a port has been loaded for consumers to check. Adds tests to confirm the expected properties on the port and value of loaded at the various RemotePage:* messages.
MozReview-Commit-ID: IXJLvFCgbEH
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
Changes to Promise tests designed to test .then(null) have been reverted, and the browser/extensions directory was excluded because the projects it contains have a separate process for accepting changes.
MozReview-Commit-ID: 1buqgX1EP4P
The the state will be properly set in the show() call anyway, and the xulstore
doesn't track attribute removals which led to improper checked state
MozReview-Commit-ID: rGb6Td55eW
The MOZ_TELEMETRY_REPORTING define does not control whether or not Telemetry is enabled
but rather if it will send the gathered data to Mozilla servers. We still want to
display the about:preferences options and let developers know about this behaviour.
Please note that this patch is not changing any behaviour: it's only making it explicit
by showing the options as disabled rather than hiding them.
MozReview-Commit-ID: 7A0y0E0hm0Q
The MOZ_TELEMETRY_REPORTING define does not control whether or not Telemetry is enabled
but rather if it will send the gathered data to Mozilla servers. We still want to
display the about:preferences options and let developers know about this behaviour.
Please note that this patch is not changing any behaviour: it's only making it explicit
by showing the options as disabled rather than hiding them.
MozReview-Commit-ID: 7A0y0E0hm0Q
Since we now have a store of notifications that is global across
all windows, it no longer makes sense to consume the API from
within browser.js. This patch moves the browser.js logic out into
a jsm file that is wired up through nsBrowserGlue, such that it
will be lazily instantiated on the first update event it would
receive[1].
We decided to move this into toolkit, as this piece of the
system is fairly generic and shouldn't differ between
applications.
[1]: There is a change to nsBrowserGlue to use "global[module]"
instead of this[module]. This mirrors the code for all the other
types of notifications, and I suspect it was just a latent bug,
since the original diff that includes this line makes no use of
it.
MozReview-Commit-ID: 8EQdM9BOpgl
