(In reply to Florian Quèze [:florian] from comment #0)
When running browser/base/content/test/performance/browser_startup.js locally, I get a failure saying:
FAIL resource://gre/modules/Preferences.jsm is not allowed before first paint
The cause is "resource://gre/modules/URLDecorationAnnotationsService.jsm":7:36
Sorry about that!
Looking at the code, the first problem that jumps at me is that https://searchfox.org/mozilla-central/rev/e62c920f7f6463239c6634113f8a8351e263b936/toolkit/components/antitracking/URLDecorationAnnotationsService.jsm#7 imports Preferences.jsm eagerly instead of lazily.
Then the second problem is that this new code is using the deprecated Preferences.jsm
Oh wow, Preferences.jsm is deprecated? I didn't know that. Should we make that obvious by, let's say, documenting that inside the file? :-)
to do something that wouldn't be significantly harder to do without it: https://searchfox.org/mozilla-central/rev/e62c920f7f6463239c6634113f8a8351e263b936/toolkit/components/antitracking/URLDecorationAnnotationsService.jsm#33-38
Oh OK. So the preference now is to use the raw XPCOM APIs in lieu of Preferences.jsm? I can certainly do that here...
And finally that leads to the question: why was the test failure not happening on infra? I just found the answer: antitracking.manifest was not added to https://searchfox.org/mozilla-central/source/browser/installer/package-manifest.in in bug 1568341, so this component only gets initialized during startup for non-packaged local builds.
Oops, that actually answers another question which I was trying to figure out the answer to right now... (I wish writing code that added files that needed to be packages didn't require a Master's Degree in Mozilla Packaging Sciences, I have repeatedly failed to obtain that degree throughout the years.)
I was going to say that this code really needs a test, but it actually does have a test, which forces the initialization of the service at https://searchfox.org/mozilla-central/rev/e0b0c38ee83f99d3cf868bad525ace4a395039f1/toolkit/components/antitracking/test/browser/browser_urlDecorationStripping.js#37-39, hiding the problem. These lines in the test file should be removed if this service is expected to be started automatically during startup.
The test for this service is fine as is. The reason why the test is written in the way that it is is to allow for the test to be run both as a stand-alone test (e.g. with the verify suite) and as part of the per-directory suites. When the test runs stand-alone, it may very well start well before the service has finished its initialization tasks, and the point behind
await uds.ensureUpdated(); lines in the test is to eliminate that race condition...