This option shouldn't be used for local builds (see bug 1294157). Set
the option from the crate's taskcluster script instead, so that it's
used only for automated builds.
--HG--
extra : rebase_source : 94b398a0f1fac60094269d755735c426ecc63e17
Without XPCOM and related method, I want to remove dependencies of nsIDOM*
from spellchecker. Also, it is unnecessary to use nsISelectionPrivate since
we can use mozilla::dom::Selection instead.
MozReview-Commit-ID: 1Zheq3Hsepj
--HG--
extra : rebase_source : 593134f0120cc0806e63253c586e384871463414
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
* Add a new labelled-checkbox component, and use it for the persist checkbox in basic card add/edit form
* Pass an isPrivate flag from the parent to UI in the state
* Re-work save logic for the basic card form to set correct defaults when payment is initiated from a private window
* Add a tempBasicCards object on the state, and a paymentRequest.getBasicCards(state) helper to get the union of both saved and temporary cards
* Set a newly added temporary card as the selectedPaymentCard
* Tests for basic-card-form.js in private windows, and correctly persisting or not new card info basic on the state of the 'Save to Firefox' checkbox
* Add paymentRequest.js to mochitests, pending landing of bug 1427939
MozReview-Commit-ID: 9oQ1gbHPojf
--HG--
extra : rebase_source : 947b74d62d9257d1ee27dbaffe47e9f907543518
We no longer need them since in the previous commit we make sure subsequent
ticks happens for animations in delay phase.
MozReview-Commit-ID: F68wCCsCEiE
--HG--
extra : rebase_source : 0f7d1b3ef45b9dd210473d3c374d193e3ee94e83
If the animation is in delay phase, we shouldn't produce any values for the
animation but we have to make sure subsequent ticks happen in order to the time
when the animation starts. So what we should do here is that
1) Make AnimationHelper::SampleAnimations() return boolean, return true if
there is any animation.
2) Schedule the next tick if AnimationHelper::SampleAnimations return true
This setup is equivalent to what we do non-WebRender.
So that we don't need to set non-animated value as AnimatedValue for delay
phase to make subsequent ticks happen for the delay phase animations. The
non-animated value will be dropped in the next patch.
MozReview-Commit-ID: IwltLGgvT7K
--HG--
extra : rebase_source : 9854b182134adf3060260849741142841721d65b
Ekanan Ketunuti
Tiberius Oros
Robin Templeton
Jan de Mooij
André Bargull
Andreea Pavel
Makoto Kato
Boris Zbarsky
Jeff Walden
Dorel Luca
Brian Birtles
Kris Maglione
Shane Caraveo
arthur.iakab
Gurzau Raul
Robert Longson
sotaro
Lee Salzman
Christoph Diehl
Masayuki Nakano
Igor Oliveira
Andrew Swan
Johan Lorenzo
Mihai Tabara
Jared Wein
Sam Foster
Hiroyuki Ikezoe