The current API makes the life time and ownership of the result array unclear
without careful reading. The result array is always owned by the principal,
and its lifetime tied to the lifetime of the principal itself. Returning a
const array reference makes this clear, and should prevent callers from
accidentally modifying the returned array.
MozReview-Commit-ID: 3f8mhynkKAj
--HG--
extra : source : 237acf2879f6222bc4b076c377bf026d18a6ebef
extra : amend_source : dfaf6e88e3c4758f7fdcf7fb422d457edafab1b7
The current API makes the life time and ownership of the result array unclear
without careful reading. The result array is always owned by the principal,
and its lifetime tied to the lifetime of the principal itself. Returning a
const array reference makes this clear, and should prevent callers from
accidentally modifying the returned array.
MozReview-Commit-ID: 3f8mhynkKAj
--HG--
extra : rebase_source : d2a5e0862f8c964fb5a3e46b50c2e9629b218699
extra : amend_source : 27d7a7ef5da6fe2aa1104009b6ee067465db73e1
ChildPrivileges is a leftover from the B2G process model; it's now
mostly unused, except for the Windows sandbox using it to carry whether
a content process has file:/// access.
In general, when sandboxing needs to interact with process launch, the
inputs are some subset of: the GeckoProcessType, the subtype if content,
various prefs and even GPU configuration; and the resulting launch
adjustments are platform-specific. And on some platforms (e.g., OS X)
it's all done after launch. So a simple enum used cross-platform isn't
a good fit.
MozReview-Commit-ID: K31OHOpJzla
--HG--
extra : rebase_source : 3928b44eb86cd076bcac7897536590555237b76b
This is mostly based on the BSD version, which in turn is more or less
the Mac version minus some race conditions. The Linux version does
something similar, but more verbosely and (at least in my opinion) is
harder to follow. Some changes have been made, mainly to use C++11
features like UniquePtr.
MozReview-Commit-ID: 3Gv4DKCqWvu
--HG--
extra : rebase_source : 972264a778b9361d1259851554b5b7ae8f3dcdc6
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
Avoid going through GeckoAppShell and move the start child process JNI
call directly to GeckoProcessManager.
MozReview-Commit-ID: KU62TiHVQJX
--HG--
extra : rebase_source : 0e8546da502257e1c59bc00b79f50c79a314f3e6
After the previous patch, all that is needed to pass eslint is some
whitespace fixes I generated using:
./mach eslint --fix ipc
The .eslintrc.js file makes eslint expect XPCShell global variables.
With those two changes, eslint can be enabled for the ipc/ directory.
MozReview-Commit-ID: BqSICp2iV6O
--HG--
extra : rebase_source : ccab8be9fc1ae1116ae55631d3978c39d35cad05
I don't fully understand what this test is trying to do, but as far as
I can see, test_ipcshell_child.js does nothing when loaded from
test_ipcshell.js besides define a few variables, so just define them
directly in test_ipcshell.js. I am doing this because eslint does not
like the way the test is currently written: the definition of runtime
in another file confuses it, and it does not like the assignment to
run_test.
MozReview-Commit-ID: Ek0HY9n49eZ
--HG--
extra : rebase_source : 5c99b20afe93c085a198e7824e82207be347f26b
Never store names in Message. One can get string names from
Message::name() or use IPC::StringFromIPCMessageType() when only
message id is available.
MozReview-Commit-ID: 15ksx6SE90c
--HG--
extra : rebase_source : 1a041dc365b7f42edd540d8c7a4dfd8912e48921
xpcshell can sometimes create and then almost immediately kill the GPU process. This can
cause the connection state of GPUParent's message channel to be in error or closed
when it attempts to send its build ID. In this case we should ignore the request
because the process will soon close.
MozReview-Commit-ID: EAupU844iFo
--HG--
extra : histedit_source : df05a01df5ad095b4e3c91e0e038d4e145da5f9d
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: B5Y8KyExPQ8
--HG--
extra : rebase_source : e27b266c145daa5acd887e998c6d5b408101e1db
extra : source : 33f49977a33cbdb1c7127871b940eefccc018f65
Each protocol in IPDL has a bunch of autogenerated functions that
instantiate IPC::Message with various parameters. Each of these
functions, then:
1) Pays the cost of calling malloc()
2) Setting up various parameters
3) Calling IPC::Message()
There's no reason that we should be duplicating 1) across all of these
autogenerated functions. In step 2), several of the parameters we're
setting up are common across all or nearly all calls: the message
segment size is almost always zero, and we're always indicating that
IPDL-generated messages should be recorded in telemetry.
Instead of duplicating that code several thousand times, we can add a
small helper function that takes the only interesting parameters for an
IPDL message. This helper function can then deal with calling malloc in
a single place and setting up the common parameters. For messages that
require a custom segment size, we'll have to use the old scheme, but
such messages are uncommon.
The previous changes are not required for this scheme to work, but they
do help significantly, as the helper function (Message::IPDLMessage) can
now take four parameters, which ensures that its arguments are passed
solely in registers on Win64 and ARM. The wins from this change are
also larger than they would be without the previous parts: ~100K on
x86-64 Linux (!) and ~80K on ARM Android.
The current IPC::Message constructor takes a large number of arguments,
three of which--the nesting level, the priority, and the
compression--are almost always constant by virtue of the vast majority
of Message construction being done by auto-generated IPDL code. But
then we take these constant values into the Message constructor, we
check them for various values, and then based on those values, we
perform a bunch of bitfield operations to store flags based on those
values. This is wasted work.
Furthermore, for replies to IPDL messages, we'll construct a Message
object, and then call mutating setters on the Message object that will
perform even more bitfield manipulations. Again, these operations are
performing tasks at runtime that are the same every single time, and use
information we already have at compile time.
The impact of these extra operations is not large, maybe 15-30K of extra
code, depending on platform. Nonetheless, we can easily make them go
away, and make everything cleaner to boot.
This patch adds a HeaderFlags class that encapsulates all the knowledge
about the various kinds of flags Message needs to know about. We can
construct HeaderFlags objects with strongly-typed enum arguments for the
various kinds of flags, and the compiler can take care of folding all of
those flags together into a constant when possible (and it is possible
for all the IPDL-generated code that instantiates Messages). The upshot
is that we do no unnecessary work in the Message constructor itself. We
can also remove various mutating operations on Message, as those
operations were only there to support post-constructor flag twiddling,
which is no longer necessary.
There's no need to be repeating 'IPC::Message::' prefixes or spreading
around more ExprVar calls than we need here. Let's try to improve the
signal-to-noise ratio of this code by introducing a helper function to
inject some of the boilerplate for us.
_generateMessageConstructor takes a lot of `md.FOO`-style parameters,
which could be derived inside the function by simply passing `md`.
Especially with the upcoming changes to calculate things like reply-ness
of messages, sync-ness, etc, we'd be wanting to pass even more
parameters like `md.FOO`. So let's just pass `md` in, and then we can
make all the necessary future changes in a single place.
The GPU process doesn't have the directory service enabled, so it can't find
a tmp dir to put its .extra files for crash reports. Even if we do enable the
directory service, we still don't get the correct "content process tmp dir" in
the GPU process, because the UUID baked into that folder is passed via the
preferences service, and that isn't initialized in the GPU process either.
Rather than unneccessarily initialize all this stuff in the GPU process just
to get one folder name, we can pass that folder name directly in the argv list.
See comments 12-19 on the bug for further discussion of the various solutions
attempted/explored.
MozReview-Commit-ID: 1sFg27hIe7S
--HG--
extra : rebase_source : 78eb600a58fed45800b9df8303cc4d6898d96ae9
This function is very large and has many nested ifdefs. Without this cleanup
it was really hard to figure out where all I needed to add code.
MozReview-Commit-ID: IeA0AWW62Mn
--HG--
extra : rebase_source : a8447df42c60da79f1c982111c8f65bd0175f1de
The GPU process doesn't have the directory service enabled, so it can't find
a tmp dir to put its .extra files for crash reports. Even if we do enable the
directory service, we still don't get the correct "content process tmp dir" in
the GPU process, because the UUID baked into that folder is passed via the
preferences service, and that isn't initialized in the GPU process either.
Rather than unneccessarily initialize all this stuff in the GPU process just
to get one folder name, we can pass that folder name directly in the argv list.
See comments 12-19 on the bug for further discussion of the various solutions
attempted/explored.
MozReview-Commit-ID: 1sFg27hIe7S
--HG--
extra : rebase_source : 62ff819c5b03f642cd4b9af7c89c84b790397372
This function is very large and has many nested ifdefs. Without this cleanup
it was really hard to figure out where all I needed to add code.
MozReview-Commit-ID: IeA0AWW62Mn
--HG--
extra : rebase_source : a8447df42c60da79f1c982111c8f65bd0175f1de
The nsIU2FToken and its implementors are no longer needed; the soft token was
re-implemented into dom/webauthn/U2FSoftTokenManager.cpp during the WebAuthn
implementation. When the dom/u2f/ code changed to the implementation from
WebAuthn, the old synchronous version became dead code.
This patch removes the dead code.
MozReview-Commit-ID: 2yDD0tccgZr
--HG--
extra : rebase_source : 0f14d8de8f62599a41c13aa4d8fc9cdbc1fd79c7
Since LinearHistogram and its descendants inherit ranges_ from
Histogram, and we wanted to replace the copying into a std::vec
for Histogram, the simplest approach seemed to just be to
precompute ranges for all histograms, exponential or otherwise.
This should have the added benefit of reducing the memory
footprint for those histograms, since they will benefit from the
deduplication work that the precomputing script already does.
MozReview-Commit-ID: JTV5Dej5ZIb
--HG--
extra : rebase_source : de942d54b3475be54c70d43d2fa8e772ee2e18c4
Since NoFocusState is am empty struct used in the |mData| variant in
FocusTarget, we need to add a Reader and a Writer for IPC for NoFocusState so we
can properly read and write the |mData| variant. The NoFocusState Read and Write
methods do not read or write anything, since NoFocusState does not contain any
data. This is done by creating a helper class EmptyStructSerliazer and
inheritting from EmptyStructSerializer for the NoFocusState specialization.
The |Read| and |Write| methods for FocusTarget are updated by removing the read
and write code for the individual types of |mData| and instead makes use of the
IPC read and write methods for Variant.
MozReview-Commit-ID: 3159sp6FLek
--HG--
extra : rebase_source : ff82797c26abffbd8bbcc465dc40c621be3257d0
* VariantWriter construction switched to use aggregate initialization
* Call to AsVariant was inappropriately called via |paramType| when it should
have been called via |mozilla|
* |Next::Read| call in VariantReader specialization was missing the |result|
argument
MozReview-Commit-ID: Izany7iDX0k
--HG--
extra : rebase_source : 7387e72100c7d2ba8fcfd1e5a3b6d0ce6be6c740
It's important that shmem creation/destruction messages be ordered
correctly with respect to other messages that use shmems. For example,
if we create a shmem with ID 10 and then send a message that
references shmem 10, then the creation message must be handled before
the referencing message. If shmem creation/destruction messages go in
a separate queue from other messages, this ordering may not be
preserved.
Leaving shmem creation/destruction unlabeled will give us the correct
ordering. Eventually, though, we'll need to provide a solution that
doesn't bottleneck the event queue.
MozReview-Commit-ID: 88MrslRrfnh
The WebRequest API needs to know if a given window ID is at the top level, for
various reasons. It currently figures this out by mapping a channel's load
context to a <browser> element, which tracks its current top outer window ID.
But this is inefficient, and not friendly to C++ callers.
Adding the top window ID to the load info simplifies things considerably.
MozReview-Commit-ID: Fy0gxTqQZMZ
--HG--
extra : rebase_source : bb5b1e1b3294004ca5e713fc88c4e20652296e53
Certain types (such as Shmem and Endpoint types) cannot be copied, and need to
be moved when passed around. When used with MozPromises, that means that the
promise needs to be non-shareable, and the resolve functions need to use the
correct ref qualifiers.
MozReview-Commit-ID: Kt4WZNsDErK
--HG--
extra : rebase_source : 5a96f9844df1646482aa223edf5081de9d5fc976
This interface will allow extensions running into a content process to attach
a filtering stream listener to an HTTP request in the parent process. The
content process attaches a listener by sending a message from the content
process containing the ID of the request to filter, and the ID of the add-on
making the request. The permissions and request mappings for this are handled
by the web request service added in part 2.
MozReview-Commit-ID: B7Dd3ywwCBX
--HG--
extra : rebase_source : bf67c87f03c8355109bcc1193fbcb0b1c70ef224
Bug 1360308 offloads IO operations from the main thread when we create paired minidumps.
This breaks the symmetry of paired minidumps: the thread stacks of the parent minidump
doesn't correspond to the thread stacks in the child minidumps and renders the parent
stack useless. This patch moves generation of the parent minidump back to the main
thread to keep the context of the parent process when creating paired minidumps. Child
minidump is still created asynchronously.
MozReview-Commit-ID: 9RmBAuXMPSX
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
gcc throws a warning-as-error saying that the const qualifier will be ignored by function callers.
Remove the const qualifier to remove the warning.
MozReview-Commit-ID: JRQMz6Zdcdz
--HG--
extra : rebase_source : 687a7b310270823180b848d6c65cba7ba688b2ae
This aligns the code more closely with how the input stream pump works: 0
available bytes when the stream itself told us it's ready means the stream is at
the end.
Note from asuth: This fix was originally part of bug 1371699, it was part 5.
However, its initial landing was backed out, but it is now very much needed for
bug 1393063, so I'm landing it.
--HG--
extra : rebase_source : 0675d9fd5796a90a4e206cbfa350cc5b4cd94d54
Telemetry and some performance profiles show that Msg_NotifyIMEFocus can take
a few seconds to complete, and jank the browser. With bug 1217700, it removes
the necessity of sync Msg_NotifyIMEFocus, so in this patch we make this async
for performance improvement.
MozReview-Commit-ID: 15eUwMJ2Q7H
--HG--
extra : rebase_source : b463e6e881ca5ebec00d0f76e29ca103059b3ddd
For certain use cases, it's nice to be able to target Rust debug logging to only
child processes (so you focus on web content vs. chrome running in the parent).
This adds `RUST_LOG_CHILD` which is copied to `RUST_LOG` when launching child
processes.
MozReview-Commit-ID: BWAZ4f51AW
--HG--
extra : rebase_source : 4663803f4ebd35d3fa655a2e2c404afa81671c2e
nsPrintfCString.h was not included, so it caused an error
GetStringValue was called before it was defined
MozReview-Commit-ID: HYoyWyaxqaZ
--HG--
extra : rebase_source : bf2c253cdba0c2fcf079a5b9bb275d39c6074f44
We were using std::vector::assign, which resizes the vector to
match the incoming data. This isn't what we want, as ranges_ has
already been sized to bucket_count_ + 1. Instead, just use a
copy.
MozReview-Commit-ID: EGuW5jj7Rpq
--HG--
extra : rebase_source : 616d61fc27c7e43c22ea69e11e070ba958bf20a9
When removing our Windows message loop pumping code in the content
process, a11y code on the MTA thread must have some way to wake up the
main thread. The main thread could be blocked either on a conditional
variable waiting for a Gecko event, or it could be blocked waiting on
a Windows HANDLE in IPC code (doing a sync message send). In the
former case, we wake it up by posting an event to the main thread. In
the latter case, we continue to use the asynchronous procedure call
mechanism.
MozReview-Commit-ID: FN6KWaGo9Zl
There are two problems related with EVENT__SIZEOF_OFF_T:
- When building Firefox with -D_FILE_OFFSET_BITS=64, off_t is 64 bits,
but the in-tree event-config.h still defines EVENT__SIZEOF_OFF_T to 4.
- When building Firefox *without* -D_FILE_OFFSET_BITS=64 (the default)
against a system libevent that was built with -D_FILE_OFFSET_BITS=64,
its event-config.h defines EVENT__SIZEOF_OFF_T to 8, which then
doesn't match off_t size.
For the latter, libevent actually defines its own off_t type, that
callers are supposed to use instead of off_t. So that's what our
static_assert should be checking.
--HG--
extra : rebase_source : 4231530e3c260b2cdd53e15206d48ef0779e394c
This patch also adds logging into ResolveJunctionPointsAndSymLinks to help diagnose issues that
might arise if the resolution fails or the path is not usable for some reason.
The log and exp calls in base::Histogram::InitializeBucketRange()
were showing up in profiles. This patch uses the precomputed
buckets for exponential histograms instead of computing them at
runtime. Though linear histograms do show up in the profile that
prompted this change, they contribute much less, and due to the
trivial nature of generating these, it's unlikely that a static
cache would provide much if any speedup.
MozReview-Commit-ID: IavFwoWjFhk
--HG--
extra : rebase_source : ad7d641ab2982f5cf8d202c7c382bfc26daa4bd5
The log and exp calls in base::Histogram::InitializeBucketRange()
were showing up in profiles. This patch uses the precomputed
buckets for exponential histograms instead of computing them at
runtime. Though linear histograms do show up in the profile that
prompted this change, they contribute much less, and due to the
trivial nature of generating these, it's unlikely that a static
cache would provide much if any speedup.
MozReview-Commit-ID: IavFwoWjFhk
--HG--
extra : rebase_source : 18101da322faf9477acae266e9e27f579464f8d0
Having these functions declared in the class definition and therefore
inlined means that every call site is bloated by having to store the
argument so its address can be taken and load the sizeof() constant.
There's no good reason that we should be doing this; the Read*
counterparts are also out-of-lined, which hasn't seemed to cause any
problems. Moving these out-of-line saves about 200K (!) of space on
x86-64 Linux.
nsIURI.originCharset had two use cases:
1) Dealing with the spec-incompliant feature of escapes in the hash
(reference) part of the URL.
2) For UI display of non-UTF-8 URLs.
For hash part handling, we use the document charset instead. For pretty
display of query strings on legacy-encoded pages, we no longer care to them
(see bug 817374 comment 18).
Also, the URL Standard has no concept of "origin charset". This patch
removes nsIURI.originCharset for reducing complexity and spec compliance.
MozReview-Commit-ID: 3tHd0VCWSqF
--HG--
extra : rebase_source : b2caa01f75e5dd26078a7679fd7caa319a65af14
This parameter isn't used by any implementation of onDispatchedEvent,
and keeping the parameter makes later refactorings in this bug more difficult.
MozReview-Commit-ID: 90VY2vYtwCW
We only ever use these for passing them into Endpoint construction.
Let's remove them. Removing them also shows that the corresponding
field in Endpoint is essentially read-only, so we can completely avoid
passing in protocol IDs to Endpoint.
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
Previously we used the base::StatisticsRecorder object for storage by name.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
In this re-write, we instead introduce the following lookup paths (managed in TelemetryHistogram.cpp):
- Main storage:
- (histogramId, processId, sessionOrSubsession) -> Histogram*
- (histogramId, processId) -> KeyedHistogram* (this handles subsessions internally)
- Lookup:
- (histogramName) -> histogramId
- (HistogramID) -> bool (is recording enabled for this histogram?)
This is wrapped with a few lookup functions.
This also allows us to keep HistogramIDs in the JS histogram instances now, instead of pointers to Histogram instances.
That means Histogram instance life-time management is now properly contained inside TelemetryHistogram.cpp.
MozReview-Commit-ID: 5yijGv7mc89
- A histogram name identifies a set of histogram instances, for which storage and lookup will be handled in TelemetryHistogram.cpp.
So we remove the names from histogram code.
- Various unused macros in the header are removed.
- Remaining traces of StatisticsRecorder are removed from the Histogram class code.
- Some unused methods are dropped that were about printing histograms to ASCII etc.
MozReview-Commit-ID: BF2rLSpKOJ8
The Chromium IPC histogram code used the StatisticsRecorder object for storage.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
Consequently we need to rewrite this storage, which means StatisticsRecorder is not used anymore.
MozReview-Commit-ID: 1LC7YubpKaD
Since the default size is 64, we only care about message size which is > 64 bytes.
MozReview-Commit-ID: 2vUpcaUjlNP
--HG--
extra : rebase_source : 946ae82f8fc2febd05d8fc4323145643ec97b306
Previously we used the base::StatisticsRecorder object for storage by name.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
In this re-write, we instead introduce the following lookup paths (managed in TelemetryHistogram.cpp):
- Main storage:
- (histogramId, processId, sessionOrSubsession) -> Histogram*
- (histogramId, processId) -> KeyedHistogram* (this handles subsessions internally)
- Lookup:
- (histogramName) -> histogramId
- (HistogramID) -> bool (is recording enabled for this histogram?)
This is wrapped with a few lookup functions.
This also allows us to keep HistogramIDs in the JS histogram instances now, instead of pointers to Histogram instances.
That means Histogram instance life-time management is now properly contained inside TelemetryHistogram.cpp.
MozReview-Commit-ID: 5yijGv7mc89
- A histogram name identifies a set of histogram instances, for which storage and lookup will be handled in TelemetryHistogram.cpp.
So we remove the names from histogram code.
- Various unused macros in the header are removed.
- Remaining traces of StatisticsRecorder are removed from the Histogram class code.
- Some unused methods are dropped that were about printing histograms to ASCII etc.
MozReview-Commit-ID: BF2rLSpKOJ8
The Chromium IPC histogram code used the StatisticsRecorder object for storage.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
Consequently we need to rewrite this storage, which means StatisticsRecorder is not used anymore.
MozReview-Commit-ID: 1LC7YubpKaD
Previously we used the base::StatisticsRecorder object for storage by name.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
In this re-write, we instead introduce the following lookup paths (managed in TelemetryHistogram.cpp):
- Main storage:
- (histogramId, processId, sessionOrSubsession) -> Histogram*
- (histogramId, processId) -> KeyedHistogram* (this handles subsessions internally)
- Lookup:
- (histogramName) -> histogramId
- (HistogramID) -> bool (is recording enabled for this histogram?)
This is wrapped with a few lookup functions.
This also allows us to keep HistogramIDs in the JS histogram instances now, instead of pointers to Histogram instances.
That means Histogram instance life-time management is now properly contained inside TelemetryHistogram.cpp.
MozReview-Commit-ID: 5yijGv7mc89
- A histogram name identifies a set of histogram instances, for which storage and lookup will be handled in TelemetryHistogram.cpp.
So we remove the names from histogram code.
- Various unused macros in the header are removed.
- Remaining traces of StatisticsRecorder are removed from the Histogram class code.
- Some unused methods are dropped that were about printing histograms to ASCII etc.
MozReview-Commit-ID: BF2rLSpKOJ8
The Chromium IPC histogram code used the StatisticsRecorder object for storage.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
Consequently we need to rewrite this storage, which means StatisticsRecorder is not used anymore.
MozReview-Commit-ID: 1LC7YubpKaD
On Mac developer builds, add $topsrcdir and $topobjdir paths to the application
bundle Info.plist files for the main process and plugin-container, removing the
dependency on MOZ_DEVELOPER_REPO_DIR and MOZ_DEVELOPER_OBJ_DIR environment variables.
MozReview-Commit-ID: JfFFK9sEayn
--HG--
extra : rebase_source : ab2d8dd625783326b4108eb1e4ebaf49ef8fbedb
Changes made:
* Add IPC::ParamTraits as a friend to mozilla::Variant in Variant.h.
This is required so that `tag` can be accessed in the
IPC::ParamTraits specialization.
* Add a IPC::ParamTraits specialization to IPCMessageUtils.h.
MozReview-Commit-ID: B3pGrZE1z0O
--HG--
extra : rebase_source : cb73873b87401846f79e124249c7ce00dff2de77
We removed all uses of GetBlocklistState in bug 1350640. This patch
removes the message and supporting functions from the PContent IPDL.
MozReview-Commit-ID: 4JtGAWZ0nPu
--HG--
extra : rebase_source : 4eb3c21e3768e9d8284d4eec129e099be5ef17d0
This protocol was changed in bug 1351148, but the whitelist was not
updated.
MozReview-Commit-ID: Btl5633et9T
--HG--
extra : rebase_source : 0ce70a649c83213a8a47e1b08c06d7d5743a9842
This also fixes the bug where we would always profile child processes if the
parent process had been launched with MOZ_PROFILER_STARTUP=1, regardless of
whether the profiler was still running in the parent process.
MozReview-Commit-ID: LkIpYmKJOJ1
--HG--
extra : rebase_source : 49b38bc58ded91ecc2e2fce08bcb4f2d20a13b92
* nsStandardURL::GetHost/GetHostPort/GetSpec contain an punycode encoded hostname.
* Added nsIURI::GetDisplayHost/GetDisplayHostPort/GetDisplaySpec which have unicode hostnames, depending on the hostname, character blacklist and the network.IDN_show_punycode pref
* remove mHostEncoding since it's not needed anymore (the hostname is always ASCII encoded)
* Add mCheckedIfHostA to know when GetDisplayHost can return the regular host, or when we need to use the cached mDisplayHost
MozReview-Commit-ID: 4qV9Ynhr2Jl
* * *
Bug 945240 - Make sure nsIURI.specIgnoringRef/.getSensitiveInfoHiddenSpec/.prePath contain unicode hosts when network.standard-url.punycode-host is set to false r=mcmanus
MozReview-Commit-ID: F6bZuHOWEsj
--HG--
extra : rebase_source : d8ae8bf774eb22b549370ca96565bafc930faf51
nullptr is explicitly not allowed to be cast to an int.
But uintptr_t is an unsigned int that happens to be large
enough to hold a pointer.
Return 0, which is an int.
MozReview-Commit-ID: 2SE76JuJLCo
--HG--
extra : rebase_source : b5e34b608af806fb05e9eaa4550b171e6db0eb8d
This allows specifying the highest legal value rather than a sentinel
value, to support enumerations that don't have a sentinel.
MozReview-Commit-ID: 5Vj7SnYlfkH
--HG--
extra : rebase_source : 30f567edc6c6bb75971d27226ebfc3574944a9bb
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
This commit ties it all together by dispatching keyboard actions to scroll targets
in response to keyboard inputs when we have current and valid focus state.
MozReview-Commit-ID: G7rZiS3FH5e
--HG--
extra : rebase_source : 10129d417fe8ef576cac5bda3157dd8f65b5843a
extra : histedit_source : be651a33f787f68bc764988ddc073d346e854491
Focus can change at any moment in a document. This causes non-determinism and
correctness problems for doing keyboard apz scrolling. To get around this, we
will maintain deterministic behavior for focus changes initiated by input events
and see if we can get away with more non-determinism for things like `setTimeout`
In order to do this, we disable async keyboard scrolling when an input event is
processed that could have a event listener. We then attach a sequence number to
that input event and dispatch it to content. In content, we record the highest
sequence number that we have processed from an event, and send that on each focus
update. Using this, we can determine in APZ if we have a current focus target or
if we are still waiting for an input event to be processed and focus to be
reconfirmed.
MozReview-Commit-ID: CWcu8YEFQz4
--HG--
extra : rebase_source : 8c54a619bd4f5ee892f0cc8768a10f3e1e4e0b59
extra : histedit_source : 601ca293a028787883841adc6b40e62c0cc829e5
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
This patch gives some structure and order to the profiler's API.
It also renames AutoProfilerRegister as AutoProfilerRegisterThread, to match
profiler_register_thread().
This moves the I/O operations of writing minidumps in CrashReporter::CreateMinidumpsAndPair()
off the main thread and use callbacks to notify the completion of the operations.
MozReview-Commit-ID: 9wpTDDUp9GN
This changes CrashReporterHost::GenerateMinidumpAndPair() and up the caller chain to use callbacks so we
may call it synchronously or asynchronously.
MozReview-Commit-ID: 4PQH6cVdOk0
Cleans up CrashReporterHost::GenerateMinidumpAndPair() and move it to CrashReporterHost.cpp.
Also removes the call to open a privileged process handle and get the already open handle
from GeckoChildProcessHost.
MozReview-Commit-ID: 8wLm1hf8zrJ
ipc/chromium/src/base/string_util.cc:35:3 [-Wunused-member-function] unused member function 'EmptyStrings'
ipc/glue/BackgroundParentImpl.cpp:405:3: warning: unused member function 'InitUDPSocketParentCallback' [-Wunused-member-function]
The class InitUDPSocketParentCallback was added in bug 1109338. It wasn't used then and it isn't used now.
https://hg.mozilla.org/mozilla-central/rev/eefcbe8e6a0c
MozReview-Commit-ID: BfDbQ5dfgo8
--HG--
extra : source : 7411baa0c64638b9da7de813c578fe9505625690
extra : intermediate-source : 975014d05919be2c9c6a0672c1ae94da86ccb29b
Kris Maglione
Sebastian Hengst
Dan Banner
Jed Davis
evilpies@gmail.com
Nicholas Nethercote
Andrea Marchesini
Tom Ritter
Jim Chen
Mike Hommey
Wes Kocher
Aaron Klotz
Gian-Carlo Pascutto
Benjamin Smedberg
Andrew McCreight
Arthur Edelstein
Petr Sumbera
Ryan VanderMeulen
Kan-Ru Chen
Ryan Hunt
Bevis Tseng
Bill McCloskey
Dan Minor
Chris Peterson
Nathan Froyd
Markus Stange
Kartikaya Gupta
J.C. Jones
Bob Owen
Doug Thayer
Jeff Hajewski
Chris Manchester
Nicolas Silva
Jan Varga
Jan de Mooij
Cervantes Yu
Gabriele Svelto
Eric Rahm
Boris Zbarsky
Henry Chang
J. Ryan Stinnett
Masatoshi Kimura
Stone Shih
Carsten "Tomcat" Book
Jason Orendorff
Georg Koppen
Dean
Till Schneidereit
Chris H-C
Georg Fritzsche
Christoph Diehl
Marco Castelluccio
Sylvestre Ledru
Lee Salzman
Kevin Chen
Haik Aftandilian
Kyle Machulis
Samael Wang
dan1bh
Valentin Gosu
Botond Ballo
sotaro
Michael Layzell
David Anderson
Honza Bambas