Some assertions are also removed because they are no longer necessary.
The script generating the flags guarantees those assertions hold.
MozReview-Commit-ID: BgXMBoRBJaJ
--HG--
extra : source : 9c528e502e6c5e83012402e5b3c193472f00d6d0
extra : amend_source : 3bb111571c319e89f93d4759d3fa2c99bf4977bb
So that hacking on this header can be less painful...
MozReview-Commit-ID: LmpMnF7q9RG
--HG--
extra : source : b68215ade7403ae9c6fbf20cb64a64c04a67ee66
This adds repackage-signing on mac and linux, depending on repackage and the chunking-dummy kinds respectively, and repackage-signing is extended to create gpg signatures. The signing_dependencies are no longer added because the beetmover_repackage_partner.py transform is going to set that up manually, and it avoids duplicate targets which the schema blocks.
Beetmover can depend now on repackage-signing for all platforms, and no longer has any indirect dependencies to worry about, but does need to know about copying the .asc files as upstream artifacts.
MozReview-Commit-ID: JcIdXQ2B7Rg
--HG--
extra : rebase_source : d05f1092b72e4241ff2f40b286cbe0f8af94ea67
This margin only appears to be needed on Mac hence this patch makes the setting
apply only on OSX. It also switches to using logical properties so that the
margin appears in the correct place in RTL builds.
MozReview-Commit-ID: Chp1HJcretg
--HG--
extra : rebase_source : ef16f6175628be864b002ddf8d3a318570e39942
* 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
It seems to me that only the remaining three types are actually used by
the devtools, so I remove other types to reduce the scope.
MozReview-Commit-ID: 5mm3nl9qOyQ
--HG--
extra : rebase_source : 3af817ced34fdd08df8d18e25d3834eb19a21652
extra : source : 452a68930d96300a0ac35f1a261f72a2fa04e513
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
Navigation events now require a "remoted" target. Add `makeRemote` calls to a
tests which make use of these features.
MozReview-Commit-ID: GJsleBWryCd
--HG--
extra : rebase_source : 37ffaac7215b2458a82b8a7a2a59fa4321e370b8
DevTools targets have used a local progress listener for a long time to track
tab navigation. However, this is redundant with server side code that does the
same thing.
Removing this from the target reduces differences between local and remote
debugging. It also simplifies one piece of the target, which is a massively
twisted module.
MozReview-Commit-ID: E7lm4GUFZQO
--HG--
extra : rebase_source : 602128c1bd166d2278251600a39eeed5e941ea2e
Previously, we had a single mac signing task that signed all mac locales and subpartners in a single signing task. This task required us to bump the signing task timeout. Chunking gives us a speed boost and a bit more resiliency if a single signing task fails - we don't have to re-sign everything, only the tasks that fail.
MozReview-Commit-ID: 4vPZE1vzZoQ
--HG--
extra : rebase_source : 320e9b51061b57d65d08aed1e621983e911c7b6d
extra : source : 00c8d34184b954d259c04459da916bda8baaca78
Because the transforms are generators, we actually call them from the bottom up. The previous transforms don't get called until the `for task in tasks:` or `for job in jobs:` in the following transform.
Moving the `check_if_partners_enabled` transform to the end means we never try to access `config.params['release_partner_config'].values()` in `add_command_arguments` when `release_partner_config` is None. Otherwise, we hit errors when we run taskgraph-gen.py.
MozReview-Commit-ID: Ho2odPL9FxS
--HG--
extra : rebase_source : 51406b39c358ff99690e073920a2e3f66cb39c83
extra : source : 02136f9beec0726098d9263f84f46244bd454b9f
The behaviour of Android Firefox Account instances recently changed in
the face of system "Clear data" commands. To align more closely with
common Apps like Dropbox and Whatsapp (which generally don't use
Android Account instances), after a "Clear data" a Firefox Account is
moved to the Separated state, requiring the user to re-connect them
with a password challenge. To achieve this, newly created accounts
include a first run UUID; after a "Clear data", the App is killed and
restarted, Sync sees a different first run UUID, and the Account is
moved to the Separated state. (I honestly don't know what happens if
the Sync code never sees a different first run UUID, but that's for
another day.) If the user then, in the same first run session,
re-connects the Firefox Account... the Sync code will again see the
different first run UUID and move the Account to the Separated state.
This patch updates the first run UUID when the Account is
re-connected, breaking that cycle.
MozReview-Commit-ID: 9jcO9Ym54an
--HG--
extra : rebase_source : be92a7ab0f36563e7b3af69f42095dc2b244bdd2
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
Adds a test for code landed in bug 1450199.
Opens two tabs in different processes then sets cookies in one followed by checking the value in the other.
MozReview-Commit-ID: 605k68Kl7nA
--HG--
extra : rebase_source : 4efc6cf95d45b13ecbf50e51ce3134d87990fcbd
Navigation events now require a "remoted" target. Add `makeRemote` calls to a
tests which make use of these features.
MozReview-Commit-ID: GJsleBWryCd
--HG--
extra : rebase_source : 2319d43ea29cfa33850295ff2d4c902e22ae3727
DevTools targets have used a local progress listener for a long time to track
tab navigation. However, this is redundant with server side code that does the
same thing.
Removing this from the target reduces differences between local and remote
debugging. It also simplifies one piece of the target, which is a massively
twisted module.
MozReview-Commit-ID: E7lm4GUFZQO
--HG--
extra : rebase_source : b8998b391f0f6036b00c205dbf2577bd8f853ea6
