The problem is due to sanitization happening too late in the shutdown cycle.
The Sanitizer depends on Places shutdown, that recently moved to async shutdown.
That change caused shutdown to happen completely at profile-before-change, unfortunately
during that phase it's impossible to predict which services are already shutdown.
The patch restores the previous Places shutdown procedure, thus clients are notified
earlier, during profile-change-teardown.
Additional meaningful changes:
* Fixes FX_SANITIZE_TOTAL telemetry to properly count total time taken by sanitize.
* Makes each cleanup operation isolated from other errors to try cleaning up as most as possible.
* In case of multiple sanitization sub steps, each step is isolated by a try/catch, the last seen exception is reported upstream.
* Makes FX_SANITIZE_HISTORY actually measure history, not other random stuff.
* Removes TOPIC_SIMULATE_PLACES_MUST_CLOSE_1 since we can now just use profile-change-teardown for shutdown phase 1.
MozReview-Commit-ID: HroLvbi25IC
--HG--
extra : rebase_source : 5cd01a803fbc1f72dc5174dd0c5a5b5aea473fc2
Mostly just declaring globals that Cu.imports defines but there are some actual
bugs here that have been fixed as well as one test that just never ran because
of a hidden exception.
MozReview-Commit-ID: J6uIpYp8ANx
--HG--
extra : rebase_source : 5c19b92e4242088b6fc7a268f255fe9a795928f6
extra : source : 3e5b6df276a9a20fe7b3655656e62a09bc46aaa9
xpcshell tests used to use head_*.js files so this adds those for global
discovery.
MozReview-Commit-ID: BOsoGIpwdgu
--HG--
extra : rebase_source : ef36531641cbd353625019f8deba333cfd352891
extra : source : 70eca07367f40a9b4fe8c6e23ec0aef73bf2a962
This defines a few additional globals but also turns on the browser environment
for everything in browser and toolkit. This may lead to some false negatives
but we have lots of code that runs in a browser context so in the name of
getting rules turned on I think this is a useful step.
MozReview-Commit-ID: BdWouZGK6d
--HG--
extra : rebase_source : a88116d149af76aa35ee0757b3b51b6f97646ebe
extra : source : 04c1740aa49904a56bd662ee0c8aed69e6f99f8b
This adds more of the scripts that browser.js relies on and also makes
browser-chrome head files import the browser.js globals.
The MOZ_JSDOWNLOADS block in contentAreaUtils only seems to hide a single
function, I don't see any need to keep hiding that now we're on by default.
MozReview-Commit-ID: 5zvF3JtJrZG
--HG--
extra : rebase_source : 94daff602b51d7ad57a24872d9eba9b304cf2da9
extra : source : b554c7ce41c42f16c2279ae88fd9567da7509bff
To properly lint XBL files we need to support things like import-globals-from
and other ESlint comment directives so we have to pass comments through to the
code blocks that ESlint parses. Unfortunately the way the XBL processor works
now is by passing a separate code block for every method/property/etc. in the
XBL and ESlint doesn't retain state across the blocks so we would have to prefix
every block with every comment. Instead this change makes us output just a
single block that roughly looks like this:
<comments>
var bindings = {
"<binding-id>": {
<binding-part-name>: function() { ... }
}
}
This has some interesting bonuses. Defining the same ID twice will cause a lint
failure. Same for the same field in a binding. The line mapping is a little
harder and there are still a few lines that won't map directly back to the
original file but they should be rare cases. The only downside is that since
some bindings have the same binding declared differently for different platforms
we have to exclude those from linting for now.
MozReview-Commit-ID: CAsPt5dtf6T
--HG--
extra : rebase_source : 91a60ef0359ef53093fe197ed63dbc4e1a9f10a5
extra : source : 01675e4828b524c04a9057d68b41e9cc01ca1bb9
While working on turning on no-undef I discovered that the various rules we
have for defining globals are a little inconsistent in whether the files they
load recurse through import-globals-from directives and none of them imported
eslint globals directives.
I think we're better off putting all this global parsing code in a single place
rather than spread across multiple rules. Have one rule to turn it on for
parsed files and one function to load globals from other files and make them
share most of the code so we won't get inconsistent. If we find us needing to
turn on/off individual features we can figure out a way to do that in the
future.
This patch does that, the globals.js file does all global parsing with a shared
object that receives events from the AST, either through from an ESlint rule
or from a simple AST walker using estraverse.
MozReview-Commit-ID: 9KQZwsNNOUl
--HG--
extra : rebase_source : 0f1cceca29ac398be97a55bbcd09fe58a8be1435
extra : source : 878db4caf845282f06542793bc4b5c24fa658c14
