Consts aren't used in JS anyways, so there's no reason for them to be
in the IDL.
Differential Revision: https://phabricator.services.mozilla.com/D11715
--HG--
extra : moz-landing-system : lando
This allows Valgrind to recognize the call stacks to this function,
avoiding Valgrind warnings in intentional leaks in these functions.
Differential Revision: https://phabricator.services.mozilla.com/D13036
--HG--
extra : moz-landing-system : lando
Changes for nsIDOMWindowUtils.getOMTAValue is in the next commit with come test
cases.
Differential Revision: https://phabricator.services.mozilla.com/D13001
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13073
--HG--
extra : moz-landing-system : lando
It should be made clear that only those preferences should be added
to marionette.js which have an immediate effect. All others which
eg. require a restart, or have to be set before the application
starts the first time, must be added to the appropriate client's
profile generation code.
Differential Revision: https://phabricator.services.mozilla.com/D13059
--HG--
extra : moz-landing-system : lando
Many of the inline assembly macros in these files get reformatted
poorly by clang-format, so don't format them for now. In followup
work, in bug 1510781, hopefully we can write a larger patch to only
disable clang-format for the specific macros and then format the rest
of the files.
The problematic include STUB_ENTRY and STUB_MANGLED_ENTRY.
Differential Revision: https://phabricator.services.mozilla.com/D13311
--HG--
extra : moz-landing-system : lando
nsCRTGlue.cpp has a few data tables that get broken up badly by
clang-format, so just disable the formatting. There are some more
tables in this file, but the arrangement doesn't seem to matter for
them.
The bloat log header is just a little bit of ASCII art, so just ignore
it in formatting so it is easier to read.
MOZ_COLLECT_REPORT uses very wide string constants that get rewrapped
in an ugly way by clang-format, so just disable the formatting for
them.
Depends on D13185
Differential Revision: https://phabricator.services.mozilla.com/D13186
--HG--
extra : moz-landing-system : lando
clang-format doesn't seem to reflow text when a single string constant
is represented as multiple lines of string literals to fit within 80
columns. Instead, if a single string literal is too long, it breaks
off a piece and moves it to the next line, which leads to a bunch of
choppy short string bits. The resulting string literals are still a
bit choppy, mostly because I didn't want to break up the long names of
prefs.
Here's an example of what I mean:
|--- max width --- |
"some long string literal"
"is here but it goes on for multiple lines"
This gets turned into:
|--- max width --- |
"some long string "
"literal"
"is here but it "
"goes on for multiple lines"
My patch manually would turn this into:
|--- max width --- |
"some long string "
"literal is here "
"but it goes on "
"for multiple lines"
The strings in my patch don't always end up at column 80, because the
width is set to work with wherever clang format ends up actually
indenting them.
There are more instances of this problem when MOZ_COLLECT_REPORT is
used, but that can be dealt with in another bug. There are a ton of
them.
Depends on D13184
Differential Revision: https://phabricator.services.mozilla.com/D13185
--HG--
extra : moz-landing-system : lando
Clang format does not always reflow comments correctly to get them
within 80 columns.
The major categories of failures I have noticed in xpcom/ are:
- Comments that are lists. I fixed these by manually getting them so
they'll be within 80 columns after clang-format runs.
- Comments intermixed with lists of things like enums, initializers,
or even fields in a class. It doesn't seem to associate the comment
with the item in the list correctly. The worst cases of these happen
when it changes initializer lists from having commas at the start of
each item to having them at the end. In the initializer comma cases,
I fixed them by making the commas at the end, so clang-format won't
mix things up. For other cases, I often moved the comment for an
item onto its own line, because it was not possible to have both the
comment and the item on the same line and stay within 80 columns.
- One odd case is nsEnumeratorUtils.cpp, where the end of line comment
after a NS_DECL macro confused clang-format and made it stop
realizing that the NS_DECL thing was a complete statement. I also
added a blank line to that file before a declaration because I think
that is better.
Depends on D13183
Differential Revision: https://phabricator.services.mozilla.com/D13184
--HG--
extra : moz-landing-system : lando
Clang format makes this code look pretty bad, but I think it is safe
to just remove it.
Depends on D13182
Differential Revision: https://phabricator.services.mozilla.com/D13183
--HG--
extra : moz-landing-system : lando
This patch adds some telemetry histograms:
* CONTENT_PROCESS_LAUNCH_IS_SYNC - boolean, true if the content process
was launched synchronously (blocking the main thread)
* CONTENT_PROCESS_SYNC_LAUNCH_MS - the time consumed by sync launch;
the main thread will be busy or blocked for this entire time
* CONTENT_PROCESS_LAUNCH_TOTAL_MS - the total time elapsed from the
start of async content process launch until the launch promise is
resolved and the ContentParent can be sent IPDL messages
* CONTENT_PROCESS_LAUNCH_MAINTHREAD_MS - the time consumed on the parent
process main thread during async content process launch; typically this
is due to ContentParent::Init.
* CHILD_PROCESS_LAUNCH_MS - for any kind of Gecko child process
(including plugins, GPU, etc.), the time taken in the common process
launch code (which is run off-main-thread)
The probes restricted to async content process launch don't have "async"
in the name because that will eventually become the only kind of content
process launch.
Depends on D8943
Differential Revision: https://phabricator.services.mozilla.com/D8944
--HG--
extra : moz-landing-system : lando
There are several layers to this patch:
1. GeckoChildProcessHost now exposes a promise that's resolved when
the process handle is available (or rejected if launch failed), as a
nonblocking alternative to LaunchAndWaitForProcessHandle.
2. ContentParent builds on this with the private method
LaunchSubprocessAsync and the public method PreallocateProcessAsync;
synchronous launch continues to exist for the regular on-demand launch
path, for the time being.
3. PreallocatedProcessManager now uses async launch, and handles the new
"launch in progress" state appropriately.
Depends on D8942
Differential Revision: https://phabricator.services.mozilla.com/D8943
--HG--
extra : moz-landing-system : lando
The first attempt at async launch tried to hide the asynchrony inside
IPC, by making the process seem to be launched enough to construct new
channels and send it messages, and lazily blocking on the pid/handle.
Unfortunately, in practice we wind up needing the pid/handle immediately,
and this requirement is too deeply embedded in IPC for that to be viable.
(The alternative that will be used instead -- exposing process launch via
an explicitly asynchronous promise interface -- is made simpler by
Project Fission's upcoming rewrite of how the DOM requests new content
processes.)
Depends on D8941
Differential Revision: https://phabricator.services.mozilla.com/D8942
--HG--
extra : moz-landing-system : lando
The CONTENT_PROCESS_LAUNCH_TIME_MS histogram is currently gathering times
from two different spans of the launch process and mixing them together;
it's at best a rough approximation of "launch time".
In addition, with async launch we'll want to gather different metrics
than for sync launch (see comments on bug 1474991).
So I'm removing this histogram and will replace it with separate sync and
async metrics in bug 1474991; I intend to land both bugs' patches at or
near the same time, so we won't have a gap in getting some kind of data.
Depends on D8940
Differential Revision: https://phabricator.services.mozilla.com/D8941
--HG--
extra : moz-landing-system : lando
This fixes/adjusts two things about how content process preallocation is blocked:
1. Processes aren't registered as blockers until after they launch
successfully. The main goal is to not leak a blocker if launch fails,
but we don't need to block *while* launching synchronously, because this
all happens on the main thread.
2. Preallocated processes themselves aren't blockers. The main goal
here is so that async preallocation doesn't need extra complexity to
avoid being blocked by itself when launch completes. This mostly
doesn't affect actual behavior, because we currently support at most
one preallocated process. The difference is the window from when the
process is sent its first PBrowserConstructor until when it's next idle,
where there is now no longer a blocker, but this seems to be relatively
short (~100ms) and we don't even try to launch a new process until at
least 1s + an idle runnable.
This patch does not explicitly RemoveBlocker in ActorDestroy like the
first attempt did, because it's unnecessary: this is handled in the
ipc:content-shutdown observer.
Differential Revision: https://phabricator.services.mozilla.com/D8939
--HG--
extra : moz-landing-system : lando
DecodeInclusionProof as originally implemented used the wrong convention - its
input argument should have always been an Input rather than a Reader.
Differential Revision: https://phabricator.services.mozilla.com/D11811
--HG--
extra : moz-landing-system : lando
The original implementation of Certificate Transparency included a definition
for the first version of the Signed Tree Head data structure but it was never
actually used. Now that we're implementing Binary Transparency, we need to
implement support for Signed Tree Head V2. Because the focus and approach are
different, the first step is to remove the original implementation.
Differential Revision: https://phabricator.services.mozilla.com/D11810
--HG--
extra : moz-landing-system : lando
Historically this code was part of webrtc.org but has since been removed
from upstream. Rather than maintaining it as a local diff against upstream,
we should just move it to where it is used.
Differential Revision: https://phabricator.services.mozilla.com/D13092
--HG--
rename : media/webrtc/trunk/webrtc/video_engine/browser_capture_impl.h => dom/media/systemservices/video_engine/browser_capture_impl.h
rename : media/webrtc/trunk/webrtc/video_engine/desktop_capture_impl.cc => dom/media/systemservices/video_engine/desktop_capture_impl.cc
rename : media/webrtc/trunk/webrtc/video_engine/desktop_capture_impl.h => dom/media/systemservices/video_engine/desktop_capture_impl.h
extra : moz-landing-system : lando
This adds a skipintoolbarset to the toolbar-menubar spacer and the titlebar-buttonbox-container
hbox to avoid a case where an exception can be thrown from CustomizableUI.isWidgetRemovable,
which expects all direct descendants of toolbars to either have an ID, be one of a special
set of node types, or have skipintoolbarset="true" set on it.
Differential Revision: https://phabricator.services.mozilla.com/D13147
--HG--
extra : moz-landing-system : lando
