Backed out changeset 95a6eacbef27 (bug 1722925)
Backed out changeset 2e2a98aeca5c (bug 1722925)

Differential Revision: https://phabricator.services.mozilla.com/D122321

Since the Find method does not exist on nsACString, I had to use std::search
to find the "data:" substring in the spec.

Differential Revision: https://phabricator.services.mozilla.com/D122082

Bug 1722925 - Remove NS_MutatorMethod in favor of templated nsIURIMutator::Apply r=necko-reviewers,kershaw

This basically reverts the changes in 5caa81103c00 (bug 1435671). In that bug
we switched from having a templated method to using a templated function
that returned a lambda because the templated method caused a binary size
regression on windows (MSVC). Since Firefox 67 we no longer support MSVC.
Using a lambda also required capturing the arguments by value, so it was
slightly inefficient.

This patch removes NS_MutatorMethod and makes the Apply method a template.
This improves perfomance as we can just pass the arguments to the called
function, without worrying about needing to copy them.
Since MSVC is not supported anymore, and clang and gcc didn't report a
binary size regression, this is a much better solution.

Differential Revision: https://phabricator.services.mozilla.com/D122081

This seems to fix a perma-orange for linux-ccov R2 also.

Differential Revision: https://phabricator.services.mozilla.com/D122408

Bug 1724989 - [devtools] Fix intermittent failure browser_grids_restored-after-reload.js with target-switching enabled r=jdescottes

A late unexpected reflow seems to be fired, after the connection has closed.
This seems to be an issue that has come up in other tests as well causing
intermittent failures. See https://searchfox.org/mozilla-central/rev/bb5549df90f9b0f5b453f9d8e872a94e503c64a6/devtools/client/inspector/grids/test/browser_grids_grid-outline-highlight-area.js#40

Differential Revision: https://phabricator.services.mozilla.com/D122277

It can happen that the call to `instantiateTarget` from frame-helper.js fails if
the document gets destroyed quickly. In such case, we receive an `AbortError`
and me try again to create the initial targets.
As a result, it might happens that the DevToolsFrameChild handles the actual document via the
`DOMWindowCreated` event handler which would make the `DevToolsFrameParent:instantiate-already-available`
message handling fail as we're trying to create yet another target for the same
document.
In such situation we simply don't throw anymore

This makes browser_styleeditor_loading to pass with server side target switching.

Differential Revision: https://phabricator.services.mozilla.com/D121375

The test wasn't waiting for the panel to be properly reloaded.

Differential Revision: https://phabricator.services.mozilla.com/D122363

This is follow up issue of implementing enterkeyhint attribute.

Differential Revision: https://phabricator.services.mozilla.com/D122407

Differential Revision: https://phabricator.services.mozilla.com/D122410

Differential Revision: https://phabricator.services.mozilla.com/D122406

In bug 1698883, a more general rule was removed that made the label for
the Synced Tabs panel CtA button visible: https://hg.mozilla.org/integration/autoland/rev/0ff3ea52f07954501fbcfe9e6abe2a62cfb37d9b#l7.13

Since that rule isn't around anymore, we tell the Synced Tabs button
explicitly to display itself. Thankfully, we no longer need to override
the text-align property with !important, since that was in the original
rule that was removed, and the text-shadow is already being set to none
in another rule for this button.

Differential Revision: https://phabricator.services.mozilla.com/D122371

`mozilla::profiler::ThreadRegistry` keeps a list of all `ThreadRegistration`s, and makes it safely accessible from any thread.

While a thread is accessing the list, that list cannot be changed (a thread (un)registering itself needs to acquire the associated mutex). In particular, a thread will not disappear during that time, so it's safe to access the `ThreadRegistration` data that is owned by these threads.

The subset of `ThreadRegistrationData` accessor sub-classes available through `ThreadRegistry` is different from direct on-thread access, to guarantee safe access in different circumstances.
For example, `JSContext` may be read through a `LockedRWFromAnyThread`, which requires the per-thread lock, thereby preventing any simultaneous `JSContext` change from the owning thread. And because the `LockedRWOnThread` accessor is not reachable through the registry, it's not allowed, or even possible, to change `JSContext` from other threads.

Differential Revision: https://phabricator.services.mozilla.com/D120818

This class is how a thread will register itself, and contains the thread's relevant data.
A registration-accessor object can be accessed on the thread with `GetOnThreadPtr()` or `WithOnThreadRef{,Or}()`, and from there some of the data accessor may be obtained, with per-thread lock where necessary.

(The next patch will introduce ThreadRegistry to access registrations from other threads.)

Differential Revision: https://phabricator.services.mozilla.com/D120817

Non-virtual sub-classes of `ProfilerThreadRegistrationData` provide layers of public accessors to subsets of the data.
Each level builds on the previous one and adds further access to more data, but always with the appropriate guards where necessary.
These classes have protected constructors, so only some trusted classes (in later patches) will be able to construct them, and then give limited access depending on who asks (the owning thread or another one), and how much data they actually need.

The hierarchy is, from base to most derived:
- `ThreadRegistrationData` (previous patch)
- `ThreadRegistrationUnlockedConstReader`
- `ThreadRegistrationUnlockedConstReaderAndAtomicRW`
- `ThreadRegistrationUnlockedRWForLockedProfiler`
- `ThreadRegistrationUnlockedReaderAndAtomicRWOnThread`
- `ThreadRegistrationLockedRWFromAnyThread`
- `ThreadRegistrationLockedRWOnThread`
- `ThreadRegistration::EmbeddedData` (next patch, as data member of `ThreadRegistration`)

Tech detail: These classes need to be a single hierarchy so that the upcoming `ThreadRegistration` class can contain the most-derived class, and from there can publish references to base classes without relying on Undefined Behavior. (It's not allowed to have some object and give a reference to a sub-class, unless that object was *really* constructed as that sub-class at least, even if that sub-class only adds member functions!)
And where appropriate, these references will come along with the required lock.

For example:
JSContext can only be written on the owning thread, through `ThreadRegistrationLockedRWOnThread` (which will be accessed through TLS = Thread Local Storage), which requires a per-thread lock.
Thanks to that, JSContext can be read using `ThreadRegistrationUnlockedReaderAndAtomicRWOnThread`, without lock because we're on the owning thread, so there cannot be any write at the same time.
Other threads will be able to read it as well, but they will only see it through `ThreadRegistrationLockedRWFromAnyThread`, which will require the per-thread lock, thereby preventing simultaneous writes.

Differential Revision: https://phabricator.services.mozilla.com/D120816

This class contains the same data as was in `RacyRegisteredThread` and `RegisteredThread`, but this data is kept `protected`, accessors will be added through sub-classes in the next patch, and tests in a later patch once publicly accessible.

Note that `ThreadRegistrationInfo`, `ProfilingStack`, and `PlatformData` are now directly included as values.

The stack top platform-specific code was taken from `GetStackTop()` in platform-win32.cpp and platform-macos.cpp.

Differential Revision: https://phabricator.services.mozilla.com/D120815

This class will contain platform-specific data about threads.
It needs to be public because it will be included as value into the thread registration data (to avoid a separate allocation).

Tests will be added when platform-specific code is implemented in bug 1722261.

Differential Revision: https://phabricator.services.mozilla.com/D120814

`ProfilerThreadRegistrationInfo` will replace `ThreadInfo`, and contains thread-specific information that may be kept after that thread has ended, to identify recorded profiling data about that thread.
It is public and not ref-counted because it will be included as value into the thread registration data (to avoid a separate allocation).

Differential Revision: https://phabricator.services.mozilla.com/D120813

Bug 1724848 - Make sure we unconditionally invalidate the widget and request a composite when the refresh driver tries to paint a fallback renderer. r=mstange

Differential Revision: https://phabricator.services.mozilla.com/D122391

Backed out changeset b81da25293ad (bug 1724749) for causing bustages due to UntrustedModulesData.h not being found.

CLOSED TREE

Differential Revision: https://phabricator.services.mozilla.com/D122396

Depends on D122300

Differential Revision: https://phabricator.services.mozilla.com/D122301

Bug 1722507: Get rid of extra margin to calculate the height of container correctly. r=desktop-theme-reviewers,harry

Differential Revision: https://phabricator.services.mozilla.com/D122300

Per the discussion on governance, the new DLL services module will live in
`toolkit/xre/dllservices`.

Mozglue code will live in `toolkit/xre/dllservices/mozglue` and will be linked
in with `mozglue.dll`.

Differential Revision: https://phabricator.services.mozilla.com/D122384

CLOSED TREE

Differential Revision: https://phabricator.services.mozilla.com/D122385

Spec change https://github.com/w3c/permissions/pull/248

Differential Revision: https://phabricator.services.mozilla.com/D118692

Differential Revision: https://phabricator.services.mozilla.com/D122064

The use of GRE_HOME was cargo-culted well back when, and doesn't reflect
the reality of where the executables and libraries are on Android.
Libxul and its dependent libraries are actually loaded from
MOZ_ANDROID_LIBDIR, set from the Java side, and used in APKOpen.cpp,
matching reality more closely.

Differential Revision: https://phabricator.services.mozilla.com/D122323

Differential Revision: https://phabricator.services.mozilla.com/D121936

If it has a value set, that interferes with values we set to other
PKG_CONFIG_* variables for sysroots.

Differential Revision: https://phabricator.services.mozilla.com/D122287

Bug 1721968 - Remove support for lucetc for rlbox. r=firefox-build-system-reviewers,shravanrn,mhentges

Differential Revision: https://phabricator.services.mozilla.com/D120700

While some custom builds of GCC work successfully, system GCC builds
usually don't, because of several factors:
- they don't use the C++ headers or libstdc++.so from the sysroot
- they don't necessarily know to use the multiarch directories in the
  sysroot

Differential Revision: https://phabricator.services.mozilla.com/D121946

Bug 1723953 - pre: Add min/max to the python configure sandbox. r=firefox-build-system-reviewers,andi

Differential Revision: https://phabricator.services.mozilla.com/D121945

Differential Revision: https://phabricator.services.mozilla.com/D121935

Bug 1678895 - Wait for PageStop and call promiseAllPaintsDone instead of waiting for the first-contentful-paint. r=geckoview-reviewers,agi

The first-contentful-paint doesn't ensure there's no more pending paint requests,
so if there's still pending paint requests and if one of the requests was an
important request to make sure our hit testing machinery works as expected (for
example, addEventListener triggers a paint request [1]), test doesn't work as
expected.

[1] https://searchfox.org/mozilla-central/rev/bb5549df90f9b0f5b453f9d8e872a94e503c64a6/dom/events/EventListenerManager.cpp#478

Differential Revision: https://phabricator.services.mozilla.com/D122311

Bug 1678895 - Add GeckoSessionTestRule.promiseAllPaintsDone to make sure all pending paints have been finished. r=geckoview-reviewers,agi

This function will be used in the next commit to make sure there's no remaining
paint requests before proceeding each test cases. This code was mostly copied
and pasted from the commit when we introduced flushApzRepaints in bug 1660357.

This `promiseAllPaintsDone` is a simplified version of promiseAllPaintsDone in
paint_listener.js.  Though the paint_listener version is supposed to be loaded
and supposed to add an event listener for MozAfterPaint events in the first
place, whereas this version is supposed to keep adding an event listener for a
MozAfterPaint event until there's no pending paint request when it gets called,
it's a compromise but it should work as expected in most cases.

Differential Revision: https://phabricator.services.mozilla.com/D122310

They're necessary because of cross-compilation-unit use of the
template.

Differential Revision: https://phabricator.services.mozilla.com/D122305

Bug 1724748 - Add regression tests for JSWindowActor nsITopLevelNavigationDelegate behaviour. r=smaug

Differential Revision: https://phabricator.services.mozilla.com/D122151