Cleanup of all localization notes that refer to entities
that are not listed in the corresponding localization file.
MozReview-Commit-ID: Bl0VU9HoPfa
--HG--
extra : rebase_source : 86680b8ae037783304f045e94c7af7053a0f69e9
This patch disables devtools/client/debugger/new/test/mochitest/browser_dbg-babel-preview.js when run on windows10-64-ccov.
MozReview-Commit-ID: HWoAsO0Q8tY
--HG--
extra : rebase_source : 53cb3861cdff43a8c08a56557291c27a66579435
Remove the syn dependency from gkrust-shared, which was added in bug 1373878
as a workaround for this Cargo bug:
https://github.com/rust-lang/cargo/issues/3923
MozReview-Commit-ID: L34J0davEYd
--HG--
extra : rebase_source : 79e5684cba143f6215e7dcf9367f82227bca48c5
With a common prefix, all of the URL Classifier gtests can be run
like this:
./mach gtest UrlClassifier*
MozReview-Commit-ID: IqQznsldFOD
--HG--
extra : rebase_source : 5da7496e9607083b452c915608a0ab9adae818ff
This patch enables e10s mode on all suites running on the linux64-jsdcov code coverage build.
MozReview-Commit-ID: Iex6VPhLVpJ
--HG--
extra : rebase_source : 3c9124304e33856465aacdafb3e4abf4e7ac64e9
As requested, a test for the key limit pref.
This sets it to a value lower than the limit of events we can currently send
without truncation (100), but higher than is likely to be hit by tests (since
the first time we record an event, we read the pref, so we can't unsend it).
MozReview-Commit-ID: 7pGftCa1rz3
--HG--
extra : rebase_source : b3631ef7e1f436ded1ca8c6d3e8d6a2c3987ffb2
To test the TelemetryEvents portion of the code we need TelemetryEvents
tests. (The gtests only cover portions deeper than the TelemetryScalar API).
MozReview-Commit-ID: ExaiW0OiwFI
--HG--
extra : rebase_source : 1e352e1a8c8172d92eec3270d332818e6de5ba24
Introducing the pref toolkit.telemetry.maxEventSummaryKeys which we should
hopefully never have to think about because (and yes, I risk being quoted in
future for this):
500 unique event names per process ought to be enough.
We check the preference just once but have to set it each time as the
KeyedScalar object may have been recreated while we weren't looking.
MozReview-Commit-ID: 8IE9dcfuynh
--HG--
extra : rebase_source : 1865645d75e53b9122c0855ce297b7488997d357
I considered a few different ways to do this, but storing the limit inside the
KeyedScalar itself was the cleanest. The limit check is too deep to pass it as
an argument, and making it conditional on the keyed scalar being called
"telemetry.event_counts" was too fragile.
MozReview-Commit-ID: AyfEKB40Abb
--HG--
extra : rebase_source : cdaf88cbf891682eeb1b79a0fbc4e1f8cac60501
Telemetry Events will now be counted in the keyed scalar
"telemetry.event_counts" even if their category is not enabled for recording.
The keys will be category#method#object and a follow-up commit will expand the
process limit of the number of these from 100 to 500, configurable by pref.
Unfortunately Event Telemetry needs a special API so that an event recorded in
multiple processes will be summarized to those processes separately.
MozReview-Commit-ID: 7dKcM3SXO6r
--HG--
extra : rebase_source : 42af54472ac648165ac64bc5ab5a5a666830efe8
TelemetryComms includes some ipc headers we don't have in the gtest build.
MozReview-Commit-ID: 9gK6KPHeUIa
--HG--
extra : rebase_source : 1cf09253f9bc1b5f31bdeec438ef2390a99c0bb8
This allows us to store Telemetry Event category (30), method (20),
object (20), and two delimiters (2) in a single key, like so:
oohwowlookthiscategoryissolong#thismethodislongtooo#thisobjectisnoslouch
MozReview-Commit-ID: BkoU1VAXFF9
--HG--
extra : rebase_source : b172e8dd8ee925f05545a944e340fb5a43c296b1
The maximum key length constraint should be strict greater-than, and the
maximum number of keys constraint should only be checked if we are creating a
new key.
MozReview-Commit-ID: 5fhfV8BbmRH
--HG--
extra : rebase_source : 6b55ffa83ff2960e081381425322f80d1e0ba087
Original patch by Ethan Lin <ethlin@mozilla.com>.
MozReview-Commit-ID: AAIaskIsz9x
--HG--
extra : rebase_source : 879144b98467f47867d66f2806d7d31dbcf2bc7b
The Servo side of the changes for
https://bugzilla.mozilla.org/show_bug.cgi?id=1452040
- [X] `./mach build -d` does not report any errors
- [X] `./mach build-geckolib` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because it's a trivial change to internal constants
Source-Repo: https://github.com/servo/servo
Source-Revision: a0bdba73e3f0dd52a74f75bc8191f52c3af2a62c
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 068e6ebeaa11ce792ccbb034045a008dd5df029e
Tag is unused.
This changes how some mixes of MathML and html get wrapped in anonymous table
boxes (in particular, it changes whether it uses a MathML or an HTML table
frame). The main thing this affects is whether the frame responds to certain
attributes. Responding to mathml attributes on its mContent when that mContent
is not a MathML element is weird. So arguably this is also more correct.
However, that seems acceptable to me, and you can already get that mixing
manually. On a few (arguably simple) manual test-cases mixing MathML and HTML
tables I couldn't manage to get the patched build to render differently.
Plus, neither our reftests nor the WPT MathML test-suite upstreamed by Fred Wang
for WebKit rely on this.
MozReview-Commit-ID: 8IV3iF5xIs0
