Bug 1355492 moved the logic for scanning for unsubmitted crash reports out of the initialization
of UnsubmittedCrashHandler, and the initialization is what decided whether or not it was
appropriate to scan in the first place. This was done so that scanning could be deferred
until idle after first paint.
This patch makes it so that the scanning logic first ensures that the UnsubmittedCrashHandler
is actually enabled and not suppressed (which is calculated earlier).
I've also taken the liberty of adding a regression test.
MozReview-Commit-ID: 3Aihom5Q17R
Bug 1355492 moved the logic for scanning for unsubmitted crash reports out of the initialization
of UnsubmittedCrashHandler, and the initialization is what decided whether or not it was
appropriate to scan in the first place. This was done so that scanning could be deferred
until idle after first paint.
This patch makes it so that the scanning logic first ensures that the UnsubmittedCrashHandler
is actually enabled and not suppressed (which is calculated earlier).
I've also taken the liberty of adding a regression test.
MozReview-Commit-ID: 3Aihom5Q17R
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.
* Toggle animate=false attribute on arrow panels when toolkit.cosmeticAnimations.enabled is false
* Use preferences-service component to lookup the pref in the arrowpanel binding
* Disable this pref during tests to remove a source of instability and timing-based test failures in chrome/UI tests.
* Enable cosmeticAnimations for tests which depend on existing behavior
* Re-enable cosmeticAnimations pref for browser_ext_popup_select.js which is known to be more reliable with animations
MozReview-Commit-ID: IvA2ySPPmeJ
* Toggle animate=false attribute on arrow panels when toolkit.cosmeticAnimations.enabled is false
* Use preferences-service component to lookup the pref in the arrowpanel binding
* Disable this pref during tests to remove a source of instability and timing-based test failures in chrome/UI tests.
* Enable cosmeticAnimations for tests which depend on existing behavior
* Re-enable cosmeticAnimations pref for browser_ext_popup_select.js which is known to be more reliable with animations
MozReview-Commit-ID: IvA2ySPPmeJ
