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
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
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
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