Since comm-central doesn't have integration branches like autoland, we want to
always disable sccache on nightly builds, rather than being able to key off of
the tree to determine whether to enable it. This is currently done by not
including the sccache toolchain. However, the mozconfig files expect sccache to be
available if `SCCACHE_DISABLE` isn't set, which wasn't the case on windows.
Differential Revision: https://phabricator.services.mozilla.com/D603
--HG--
extra : rebase_source : 565d0b6a3b24a23f6ae844a8cd97b9824e9f5282
extra : amend_source : 8c1679a71a2baf04a0dc83074234c5101705b806
Also, change DocumentFragment to use RefPtr, since that's the usual style.
MozReview-Commit-ID: 4PQ19nbmhUh
--HG--
extra : rebase_source : 2afb214b764ba48a4a8718190a6853ae6d6ea80b
maxTextLength is unused from script, so I would like to move to TextEditor.
Also, there is no reason to keep setText on nsIPlainText.
MozReview-Commit-ID: CZ8pa9Pm8qt
--HG--
extra : rebase_source : ea58a20510b2211dcf440955ec8dc49d57337437
This still doesn't fix everything. In particular, we need to check whether the
subproperty will be enabled in Longhands and LonghandsToSerialize too.
I haven't decided yet on what's the best way to do that.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2c060eb81a8eab0fdcbf13231bf7703ea96bc657
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : f69fc629a34488a51df7323b320b52ee2da65ab1
We now have access to workers running on EC2 instances with dozens of
vCPUs. gecko-<L>-b-linux-large is m4.10xlarge, m5.12xlarge, c5.9xlarge,
or c4.8xlarge. gecko-<L>-b-linux-xlarge is m5.24xlarge, m4.16xlarge,
or c5.18xlarge.
Experimentation reveals that Clang tasks are the only tasks that
are CPU efficient enough (read: cost effective) to run on these
larger worker types.
This commit defines the new worker types and switches Clang toolchain
tasks to run on the new workers. clang5 and clang6 tasks take ~30 minutes
on the -large variant but ~17 minutes on the -xlarge variant. All other
tasks don't show as linear of a speedup. So running them on the
-xlarge variant isn't justified.
As part of this change, Mac toolchain tasks have been converted
to run on gecko-<L>-b-linux* workers. The gecko-<L>-b-macosx64 workers
are actually Linux. IMO the b-macosx64 worker type is no longer needed.
Moving the toolchain tasks off the worker should hopefully not be very
controversial.
MozReview-Commit-ID: HynQPMWiWHo
--HG--
extra : rebase_source : 1142767e2a51c17880909ec6f15b694db8a43af2
"Include what you use."
--HG--
extra : rebase_source : 2239a380029e0efbc9dd3042459222a67c38d70f
extra : amend_source : 4453c32cc469caa592049167205666997f1a1e7b
extra : histedit_source : a533edd4a4d3d0642b08989e93674661d27baa6a%2C37d27eeef9580381ccc0de8507f60166dabf1730
In search.js, _updateSuggestionCheckboxes is already hooked up to update this checkbox
based on the preference value, including change handlers for when it changes. As a result,
having both the preference attribute and the 'manual' JS means that the actual checked and
disabled state races with which code sets the value first.
The search suggestion order preference already doesn't have a preference attribute and is
only ever updated via the JS. It seems sensible to do the same here.
MozReview-Commit-ID: Cm8evlembt7
--HG--
extra : rebase_source : 41a55211c08c911ac234ea3cbe004391d86e4a3b
The error handling logic here would fail to remove a stale raw pointer from
mInProgressImports if the EnsureURI() call failed. Fortunately, it's not
actually possible for EnsureURI() to fail in this case, because the
EnsureResolvedURI() call above already implies EnsureURI(). That said, we're
better off structuring this code to ensure that we never leave a value in
mInProgressImports after we exit the scope.
MozReview-Commit-ID: 8mnKcHL75x
--HG--
extra : rebase_source : 332b48fde97adacfefd7771185df35c217dfbe84
Set pref datareporting.healthreport.uploadEnabled=false during mochitests
and set pref toolkit.telemetry.server to a dummy server during reftests
(uploadEnabled was already false for reftest and the telemetry server was
already set for mochitests - now these prefs are consistent).
Some mochitests failed with this change; they are updated to
set datareporting.healthreport.uploadEnabled where required.
