This patch converts HashTable.h from SpiderMonkey style to Gecko style.
It was created by first running `./mach clang-format -p mfbt/HashTable.h` to
fix the whitespace, and then doing manual patch-ups, the most significant of
which were:
- Adding braces around single-statement if/else/for/while blocks.
- Renaming class members to `mFoo` form and arguments to `aFoo` form.
- Converting `typedef Old New` to `using New = Old` throughout.
MozReview-Commit-ID: LJ1emPyuAjK
Re-enable the test that was disabled in bug 1381305 and fix the
underlying issue that caused th intermittent failure in the first place.
MozReview-Commit-ID: BL9wS2fogaf
--HG--
extra : rebase_source : 685f43b2e47d80f71814385a5c8b94fd3000eac9
Also use mozilla::HashNumber where appropriate.
MozReview-Commit-ID: BTq0XDS5UfQ
--HG--
extra : rebase_source : 28f45a9b27e831e99620a2b575f373003f1301f2
Added the flag 'capture --no' to the harness_unit tests. Stdout is now displayed by default.
MozReview-Commit-ID: HZj3vntLcKI
--HG--
extra : rebase_source : 4de9697cf8cae7ed1707049609812de6f6e22387
OS key-store adapter for Windows Credential Manager.
It looks like Windows doesn't allow locking the credential manager without locking the desktop. So `lock` and `unlock` are no-ops here.
Depends on D2487.
Differential Revision: https://phabricator.services.mozilla.com/D2550
--HG--
extra : moz-landing-system : lando
This saves about 37 KiB of memory across the UA style sheets.
MozReview-Commit-ID: EoZnlmyWwxX
--HG--
extra : rebase_source : cd8ef0ba838618f9a4583b7d9896caa3a0602199
Removed the enum RustSdpAttributeType and replaced it with the SdpAttributeType enum.
MozReview-Commit-ID: IcJnbnWa4IB
--HG--
extra : rebase_source : befb118948740122dbbdd033e20176351bdd2884
A couple of changes to ensure that the mochitest harness doesn't try to
start executing changes before the mochitest extension is loaded:
1. Fix the marionette driver to wait for an installed extension to
be started before returning from Addon:install
2. Wait for extension API onStartup() handlers to finish before
considering a webextension started.
MozReview-Commit-ID: 8YEdNn6s5qh
--HG--
extra : rebase_source : 67e9abadcda82d55ac73c33367ec65cdbf7b823d
Support for the _xpcom_categories property was removed in Bug 568691,
but we left a bunch of consumers behind, and it's been cargo-culted a bit more.
We should remove the remaining remnants.
Differential Revision: https://phabricator.services.mozilla.com/D2429
--HG--
extra : moz-landing-system : lando
We may not really receive a dragend event if we're fast enough.
Calling _onDragEnd multiple times is fine (it should be idempotent).
This particular exception was added in bug 978084 along with all the _onDragEnd
calls, but I don't think it's sound over-all.
I don't really want to dig into the XUL button code to see why drag end was
consistently firing there, unless you think it's really really needed :)
Differential Revision: https://phabricator.services.mozilla.com/D2019
--HG--
extra : moz-landing-system : lando
This was causing an empty message to appear in the
browser console when clicking the clear button.
This specific call was introduced 5 years ago without
much explanation, and since the error console is now
gone, I think it's safe to remove the call.
A test is added to make sure we do not print any extra
messages when clearing the browser console.
Differential Revision: https://phabricator.services.mozilla.com/D2551
--HG--
extra : moz-landing-system : lando
Looks like these used this mechanism for no great reason, and actually doing
this exposes trivially whether fingerprinting-resistance is enabled, which looks
like an anti-goal (if a media query parses correctly, and doesn't match either 1
or 0, then fingerprinting-resistance is enabled).
Differential Revision: https://phabricator.services.mozilla.com/D2493
MozReview-Commit-ID: 76tIIkwlpeP
Always assume allowed-for-all-content. There are a couple callers which weren't
doing that:
* A unit test -> removed.
* ComputeAnimationDistance: Used for testing (in transitions_per_property), and
for the animation inspector. The animation inspector shouldn't show
non-enabled properties. The transitions_per_property test already relies on
getComputedStyle stuff which only uses eForAllContent.
* GetCSSImageURLs: I added this API for the context menu page and such. It
doesn't rely on non-enabled-everywhere properties, it was only using
eInChrome because it was a ChromeOnly API, but it doesn't really need this.
Differential Revision: https://phabricator.services.mozilla.com/D2514
MozReview-Commit-ID: 4VOi5Su3Bos
The loop was mutating the nsCSSPropertyID used to guard the exit, which is
obviously wrong.
This branch is pretty rarely taken, since people don't usually specify `all` as
a transition property other than the first, for which case we take the fast path
with `checkProperties = false`. Our test-suite failed to catch this.
Added a crashtest that hangs without this patch.
The reason bug 1478990 regressed this is because it changed the order of
nsCSSPropertyID so that `p` actually went backwards causing the infinite loop,
but the bug was introduced (by me, whoops) in bug 1309752.
Differential Revision: https://phabricator.services.mozilla.com/D2552
MozReview-Commit-ID: Ii3D1FaZ31R
The loop was mutating the nsCSSPropertyID used to guard the exit, which is
obviously wrong.
This branch is pretty rarely taken, since people don't usually specify `all` as
a transition property other than the first, for which case we take the fast path
with `checkProperties = false`. Our test-suite failed to catch this.
Added a crashtest that hangs without this patch.
The reason bug 1478990 regressed this is because it changed the order of
nsCSSPropertyID so that `p` actually went backwards causing the infinite loop,
but the bug was introduced (by me, whoops) in bug 1309752.
Differential Revision: https://phabricator.services.mozilla.com/D2552
MozReview-Commit-ID: Ii3D1FaZ31R
--HG--
extra : source : 78be4bbf4b050f6614bb9f4115f57fb61f4890df
