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
These are the only remaining flags that we don't generate from Servo
side. We can now assert flags are equal and switch kFlagsTable to use
ServoCSSPropList.h instead.
MozReview-Commit-ID: 6RhXeCf6DgK
--HG--
extra : rebase_source : 604eb046b4cc56db2e6ee2d35441000a74575368
extra : source : cdd19a8641a86d2460107e6c0f50a9d27c7bdb6c
The only difference in the final result is "all" shorthand, for which
the original result is wrong because "all" shorthand doesn't accept any
value other than the CSS-wide keywords.
MozReview-Commit-ID: BmT7kGwC0ZQ
--HG--
extra : rebase_source : 094d764007359cb928f4c31a3818448f254a4043
extra : source : 10d25cf7b4ff2b5615a638031f98dc6163708545
Most of types just derive it using proc_macro directly. Some of value
types need manual impl.
In my current plan, this new trait will be used in bug 1434130 to expose
values as well.
MozReview-Commit-ID: LI7fy45VkRw
--HG--
extra : rebase_source : a765e43b0c615e5f47bddb90ba6fa24bfc06959e
extra : source : 60812c1b190d90602bc6d49477fe1f558a53cd51
Jan de Mooij
André Bargull
Andreea Pavel
Makoto Kato
Boris Zbarsky
Jeff Walden
Dorel Luca
Brian Birtles
Kris Maglione
Shane Caraveo
arthur.iakab
Tiberius Oros
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
Chris Manchester
Xidorn Quan