Aside from making things easier for JS callers, this also makes it harder to
accidentally trigger an early load of the service, which can be expensive
during startup.
This also makes a slight change to nsPluginHost to initially preserve the
previous blocklist state when a plugin is updated, to avoid the risk of the
possible additioanl asynchrony unblocking a plugin that should stay blocked.
MozReview-Commit-ID: 4EvIGJ1Ke0Z
--HG--
rename : toolkit/mozapps/extensions/nsBlocklistService.js => toolkit/mozapps/extensions/Blocklist.jsm
extra : rebase_source : e7047615ea3a728478695c76a0c521b0281f363b
extra : amend_source : b74115abacacd17ae3e8433a534a5bbb541905b0
When the QueryInterface method for an XPCWrappedJS class is implemented by the
native helper, we can avoid a lot of overhead by simply asking it if it
supports a given interface rather than going through all of the JSAPI call and
exception handling overhead we'd need otherwise.
MozReview-Commit-ID: FVAN3oYRE9I
--HG--
extra : rebase_source : 23a42374e83ee4314fa89ead135fd2e8f9968296
The test added in this patch fails without the corresponding code changes
(specifically the second gGetComputedTimingTests test fails the comparison of
the 'easing' member).
MozReview-Commit-ID: 9eyXruVrPuN
--HG--
extra : rebase_source : 927f55c0670bf770e03d38eb876202efbb700c1e
TSFTextStore should discard pending composition update actions when it records
end composition update action because end composition update action causes
dispatching eCompositionCommit event and it replaces old composition string
anyway. So, following eCompositionChange which is dispatched by preceding
composition update actions are just redundant.
MozReview-Commit-ID: HBHx2jA15ro
--HG--
extra : rebase_source : 74d1e91d73bf9c8182a9c5e3fd55d052d8ec4bea
- Un-lazify the startup promises in ext-toolkit.js since the
manifest background property is handled asynchronously, so it
races with startup and can miss the relevant events if it
loses the race.
- Ensure that persistent events don't cause breakage when the
background-delayed-startup preference is set to false.
- Add a wakeup() method to the fire object provided to primed
listeners. This method returns a Promise that resolves when
the extension background page has started. Events that need to
do some work in the context of the extension can wait on the
result of wakeup(), then continue processing after the background
page is started, using fire.[a?]sync as normal.
MozReview-Commit-ID: HiYOguVdEQK
--HG--
extra : rebase_source : 249235553d591fec2110c213ab8b4637fe1aaf08
Avoid sending a flood of WakeSceneBuilder messages when we get a series
of updater-thread tasks to run in quick succession.
MozReview-Commit-ID: 2irXrsahMPt
--HG--
extra : rebase_source : d5663824930792c7de03ef2eeaf2e638d2f57fa8
This also fixes the grouping so that the checkboxes appear before the separator
as per the mockup here:
https://mozilla.invisionapp.com/share/M5G8OO1ZVE4#/screens
MozReview-Commit-ID: FfVNzPHEk43
--HG--
extra : rebase_source : 50f1060ab65c307a5474b40ebfb7bfaf8649070d
Normally this sort of change could be filed under "needless churn",
but by appending new files to this list we end up with constant
merge conflicts.
MozReview-Commit-ID: HnaIN2d5fOa
--HG--
extra : rebase_source : b6661417d4e7afeb8e73abe5c2ea15714b4f7dbd
On WebRender, the animation on the visibility hidden element runs on the
compositor somehow.
MozReview-Commit-ID: 77dVlIeFQ3u
--HG--
extra : rebase_source : 2b93833e9bf5ed17f3e4ee5306bdcfd57e3c87a4
We need to allocate new AnimatedValue only if there is no AnimatedValue
corresponding to the id in the hashtable.
MozReview-Commit-ID: HeRt74Tnojt
--HG--
extra : rebase_source : 6920ac7fe770e928883e9995469e972799b3c02e
PerformanceCounters are currently disabled in two ways:
- a preference that's off by default "dom.performance.enable_scheduler_timing"
- calls made only for nightly using #ifndef RELEASE_OR_BETA
In order to simplify the code, let's remove the #ifndef and rely only on the pref.
That will also allows us to use the feature in every version going forward.
The performance will not be impacted since the current code is already using
the (cached) pref value to determine if the counters are used.
MozReview-Commit-ID: 47t2M1O13aH
--HG--
extra : rebase_source : e129e1829f1dc37c019e50e156474c4876d6d6cb
This consistently shows up in profiles as taking about 6-10ms during startup.
Part of the problem is that it loads TelemetrySession.jsm, which we can't fix.
Part of the problem is that the escaping and string manipulation it does is fairly expensive. We can cache the escaped values in addonStartup.jsm to avoid that.
A lot of the problem is that we call it every time we load a bootstrap scope, even though we already set the correct value before we start loading any bootstrapped scopes, and it doesn't change after that. We can avoid this by skipping the redundant calls during startup.
MozReview-Commit-ID: 68EWdnJdPvk
--HG--
extra : rebase_source : a2ad982214634304be5adc17661c9997fc94a708
extra : amend_source : aa2038ff9d655e8d5628c70615c04f7a5101fe28
