Calling setExperimentActive too early during startup can change
the order of some initialization. setExperimentActive probably
shouldn't have this kind of effect, so simply cache early calls
to it until gGlobalEnvironment has been initialized through other
functions.
Additionally, I am speculatively including work to ensure that
setExperimentInactive and getActiveExperiments have the same
behavior, while remaining correct by working from the same cache
that setExperimentActive uses.
MozReview-Commit-ID: IlzT1J0o6gK
To cut down on complexity, we don't require specifying any expiry versions.
Given that these events will be recorded non-persistently from off-train add-ons, they can be expired by shipping new add-on releases.
We also start to use the new "record on release" terminology here instead of opt-in/opt-out, but are not changing the internal functionality yet.
Technically, this is implemented by keeping a separate registry for the dynamic event information.
Built-in & dynamic events are tracked with separate numeric ids, so introduce a common identifier for both, an EventKey.
For actual event storage, the events are treated the same as built-in events. They are simply bucketed into the 'dynamic' process storage.
This approach ends up duplicating code paths that use the event info, but keeps a single implementation for recording, storage & serialization.
This also changes the Library window to use the newly added back-end object. The only user-visible change should be how the selection behaves when retrying downloads.
MozReview-Commit-ID: 7CQr1m21rcB
Before this patch, test_logins_decrypt_failure.js would essentially call
PK11_ResetToken and then PK11_ChangePW (via nsIPK11Token.reset and
nsIPK11Token.changePassword, respectively). This was never correct (after
PK11_ResetToken, the token has no password, so it can't be changed), and after
bug 1379273 this actually fails. The correct thing to do is PK11_ResetToken and
then PK11_InitPin (nsIPK11Token.initPassword).
Add a boolean value in FindFamily() to check if gecko needs to defer the
InitOtherFamilyNames() task into idle queue.
Add a new telemetry data FONTLIST_INITOTHERFAMILYNAMES_NO_DEFERRING for the
execution time of InitOtherFamilyNames() running regularly at main thread
instead of in idle queue.
MozReview-Commit-ID: A3YPDcHtXrX
Add a boolean value in FindFamily() to check if gecko needs to defer the
InitOtherFamilyNames() task into idle queue.
Add a new telemetry data FONTLIST_INITOTHERFAMILYNAMES_NO_DEFERRING for the
execution time of InitOtherFamilyNames() running regularly at main thread
instead of in idle queue.
MozReview-Commit-ID: A3YPDcHtXrX
MozStackWalk() is different on Windows to the other platforms. It has two extra
arguments, which can be used to walk the stack of a different thread.
This patch makes those differences clearer. Instead of having a single function
and forbidding those two arguments on non-Windows, it removes those arguments
from MozStackWalk, and splits off MozStackWalkThread() which retains them. This
also allows those arguments to have more appropriate types (HANDLE instead of
uintptr_t; CONTEXT* instead of than void*) and names (aContext instead of
aPlatformData).
The patch also removes unnecessary reinterpret_casts for the aClosure argument
at a couple of MozStackWalk() callsites.
This will modify the "dom.popup_allowed_events" preference to control whether events from
user actions are allowed to open pop-up windows or not. If set to `false` then pop-ups from
user actions will not be allowed and will result in a doorhanger being displayed informing
the user that a pop-up was blocked. If set to `true` then all of the default events
will be allowed to open pop-up windows.
MozReview-Commit-ID: 8UFziq23zug
