If we are running a background thread in the launcher process to log failures,
then allowing the main thread to proceed with monkeypatching system calls is a
Bad Idea. This patch gives us an environment variable that, when set, indicates
that it is unsafe for PoisonIOInterposer to run.
This scenario is an uncommon one, but one that we must account for nonetheless.
Differential Revision: https://phabricator.services.mozilla.com/D21607
--HG--
extra : moz-landing-system : lando
Counting CPUs accesses the filesystem (sysfs or procfs), which we'd like
to disallow when sandboxed if possible, and fails silently if access
is denied. Because the CPU count rarely changes, this patch handles
that problem for the RDD process by caching a copy before starting
sandboxing.
Tested with a local patch to have the sandbox file broker client crash
if accessing the sysfs node for the CPU count, to verify that it's not
accessed.
Depends on D14524
Differential Revision: https://phabricator.services.mozilla.com/D20895
--HG--
extra : moz-landing-system : lando
This commit adds a `storage_variant::HashPropertyBag` type that
exposes an idiomatic Rust interface for `nsIWritablePropertyBag`.
Differential Revision: https://phabricator.services.mozilla.com/D21062
--HG--
extra : moz-landing-system : lando
If main thread is busy handling runnables in the normal priority queue, control-type of messages from
workers are possibly postponed to run after those. That can lead to bad performance, if the page
expects workers to be able to proceed simultanously with the main thread.
This patch makes the control messages to use medium high priority queue in order to try to
ensure they are handled in timely manner.
Pref dom.worker.use_medium_high_event_queue can be set to false to disable this new behavior.
Differential Revision: https://phabricator.services.mozilla.com/D22128
--HG--
extra : rebase_source : 447dec6dbcccaa0206a1815c21ccf713c523fc91
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
--HG--
extra : moz-landing-system : lando
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
--HG--
extra : moz-landing-system : lando
We should stop handling splitting nodes if mutation event listeners move or
remove the split nodes unexpectedly because the post processors may not be
able to keep handling the nodes. For example, if a node is moved to outside
of editing host, we shouldn't touch it anymore due to non-editable.
This patch makes `EditorBase::DoSplitNode()` return new error for making
any parent callers stop their job, but note that the following patch makes
any public methods expose the new error as exception for compatibility with
Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D20810
--HG--
extra : moz-landing-system : lando
nsSystemInfo is initialzied at first page load. Actually, content process uses
sync IPC to get Android OS information. But now, we can use Java code even if
on content process, so we should use JNI directly instead of sync IPC.
Also, nsSystemInfo still has unused extern android_sdk_version that is for
HoneyComp's DNS hack. So let's remote it.
Differential Revision: https://phabricator.services.mozilla.com/D20129
--HG--
extra : moz-landing-system : lando
This is more consistent with what the Rust bits of the style system do, and
removes a pointer from ComputedStyle which is always nice.
This also aligns the Rust bits with the C++ bits re. not treating xul pseudos as
anonymous boxes. See the comment in nsTreeStyleCache.cpp regarding those.
Can't wait for XUL trees to die.
Depends on D19001
Differential Revision: https://phabricator.services.mozilla.com/D19002
--HG--
extra : moz-landing-system : lando
The actual subcategories will be added in later patches, so that there are no
unused categories.
Differential Revision: https://phabricator.services.mozilla.com/D11334
--HG--
extra : moz-landing-system : lando
We need to preprocess these files so we can eventually add unwind
information, for which we need to include C headers.
Differential Revision: https://phabricator.services.mozilla.com/D19819
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
This is a follow-up to the previous part, which actually changes one of
these callers to use Array<nsIIDRef> instead of [array] nsIIDPtr.
From doing this patch, it seems like we should consider changing
the type `nsIIDRef` to instead simply be `nsIID`, and treat it more like
the `AString` types from the POV of XPIDL. `nsIIDPtr` would then
continue to exist for backwards compatibility, but we can probably
remove almost all current consumers over time.
Depends on D19175
Differential Revision: https://phabricator.services.mozilla.com/D19176
--HG--
extra : moz-landing-system : lando
Currently the [ref] and [ptr] types share the same underlying
implementation. This is unfortunate, and can cause correctness problems
with outparam refs (as an example).
By using the same tools used to allow other larger objects (such as
jsid, nsTArray, and nsString) to be stored directly in the nsXPTCVariant
object, this patch directly stores the nsID in the nsXPTCVariant object
when calling from JS into C++.
Using this new strategy avoids an nsID* allocation every time we pass
one over XPConnect, and should also allow us to simplify callers.
In addition, some special casing is added to xpidl to make it possible
to use the nsid reference type objects directly inside of Array<T>,
which will allow us to remove `[array] nsIIDPtr` callers.
Differential Revision: https://phabricator.services.mozilla.com/D19175
--HG--
extra : moz-landing-system : lando
Define a new RAII class, AutoDebuggerJobQueueInterruption, to save and restore
the current ECMAScript job queue, to protect the debuggee's job queue from
activity that occurs in debugger callbacks. Add a new method to the JS::JobQueue
abstract base class, saveJobQueue, to support AutoDebuggerJobQueueInterruption.
Comments on AutoDebuggerJobQueueInterruption provide details.
Implement saveJobQueue for SpiderMonkey's internal job queue and for Gecko's job
queue in CycleCollectedJSContext.
Differential Revision: https://phabricator.services.mozilla.com/D17546
--HG--
extra : moz-landing-system : lando
While the behavior of ECMAScript Promises and their associated job queue is
covered by the ECMAScript standard, the HTML specification amends that with
additional behavior the web platform requires. To support this, SpiderMonkey
provides hooks the embedding can set to replace SpiderMonkey's queue with its
own implementation.
At present, these hooks are C-style function-pointer-and-void-pointer pairs,
which are awkward to handle and mistake-prone, as passing a function the wrong
void* is not a type error. Later patches in this series must add new hooks,
making a bad situation worse.
A C++ abstract base class is a well-typed alternative. This introduces a new
`JS::JobQueue` abstract class, and adapts SpiderMonkey's internal job queue and
Gecko's customization to use it. `GetIncumbentGlobalCallback` and
`EnqueuePromiseJobCallback` become virtual methods.
Within SpiderMonkey, the patch gathers the various fields of JSContext that
implement the internal queue into their own type, js::InternalJobQueue. Various
jsfriendapi functions become veneers for calls to methods specific to the
derived class. The InternalJobQueue type itself remains private to SpiderMonkey,
as it uses types like TraceableFifo, derived from Fifo, that are not part of
SpiderMonkey's public API.
Within Gecko, CycleCollectedJSContext acquires JS::JobQueue as a private base
class, and a few static methods are cleaned up nicely.
There are a few other hooks defined in js/public/Promise.h that might make sense
to turn into virtual methods on JobQueue. For example,
DispatchToEventLoopCallback, used for resolving promises of results from
off-main-thread tasks, is probably necessarily connected to the JobQueue
implementation in use, so it might not be sensible to set one without the other.
But it was left unchanged to reduce this patch's size.
Differential Revision: https://phabricator.services.mozilla.com/D17544
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
With most of the JS components converted to static registration, the string
arena and component hashtables are much smaller than the minimum space we
allocate for them.
Differential Revision: https://phabricator.services.mozilla.com/D18474
--HG--
extra : source : 81dc12cc9257ba9c8f2eef578d99b142220b37a3
extra : histedit_source : 6f64bcd954cbc4db6970acfb5ed81717c739d13f
This commit hooks up nsFrameLoader in the child process to use the
PRemoteFrame protocol to support remote iframes. This is only activated
when a special pref is set, and the iframe has a marker attribute on it.
For example:
<iframe fission/>
In the future, we should unify nsFrameLoader to operate on a common
interface between the parent process top-level browser, and child
process subframe case. This commit just adds a new member that can
be used instead of mRemoteBrowser, when appropriate. IsRemoteFrame()
will return true for both cases.
Differential Revision: https://phabricator.services.mozilla.com/D17444
--HG--
extra : source : e33b9de7283e5fb6441e118b25af8d4ac3411bf2
extra : intermediate-source : 697a9159e0d260118ee6ebd34948d187a8c5359f
The only difference between ShutdownLoaders and ShutdownFinal was an observer service shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D18389
--HG--
extra : moz-landing-system : lando
The basic idea for the changes around UnwrapObjectInternal and its callers
(UnwrapObject, UNWRAP_OBJECT, etc) is to add a parameter to the guts of the
object-unwrapping code in bindings which can be either a JSContext* or nullptr
(statically typed). Then we test which type it is and do either a
CheckedUnwrapDynamic or CheckedUnwrapStatic. Since the type is known at
compile time, there is no actual runtime check; the compiler just emits a call
to the right thing directly (verified by examining the assembly output on
Linux).
The rest of the changes are mostly propagating through that template parameter,
adding static asserts to make sure people don't accidentally pass nullptr while
trying to unwrap to a type that might be a WindowProxy or Location, etc.
There are also some changes to places that were calling CheckedUnwrap directly
to use either the static or dynamic version, as needed.
Differential Revision: https://phabricator.services.mozilla.com/D17883
--HG--
extra : moz-landing-system : lando
The basic idea for the changes around UnwrapObjectInternal and its callers
(UnwrapObject, UNWRAP_OBJECT, etc) is to add a parameter to the guts of the
object-unwrapping code in bindings which can be either a JSContext* or nullptr
(statically typed). Then we test which type it is and do either a
CheckedUnwrapDynamic or CheckedUnwrapStatic. Since the type is known at
compile time, there is no actual runtime check; the compiler just emits a call
to the right thing directly (verified by examining the assembly output on
Linux).
The rest of the changes are mostly propagating through that template parameter,
adding static asserts to make sure people don't accidentally pass nullptr while
trying to unwrap to a type that might be a WindowProxy or Location, etc.
There are also some changes to places that were calling CheckedUnwrap directly
to use either the static or dynamic version, as needed.
Differential Revision: https://phabricator.services.mozilla.com/D17883
--HG--
extra : moz-landing-system : lando
The basic idea for the changes around UnwrapObjectInternal and its callers
(UnwrapObject, UNWRAP_OBJECT, etc) is to add a parameter to the guts of the
object-unwrapping code in bindings which can be either a JSContext* or nullptr
(statically typed). Then we test which type it is and do either a
CheckedUnwrapDynamic or CheckedUnwrapStatic. Since the type is known at
compile time, there is no actual runtime check; the compiler just emits a call
to the right thing directly (verified by examining the assembly output on
Linux).
The rest of the changes are mostly propagating through that template parameter,
adding static asserts to make sure people don't accidentally pass nullptr while
trying to unwrap to a type that might be a WindowProxy or Location, etc.
There are also some changes to places that were calling CheckedUnwrap directly
to use either the static or dynamic version, as needed.
Differential Revision: https://phabricator.services.mozilla.com/D17883
--HG--
extra : moz-landing-system : lando
Old Confluence does not aware of conflated model keypress event (see UI Events
spec, https://w3c.github.io/uievents/#determine-keypress-keyCode).
Additionally, Confluence can be hosted with any domains. Therefore, we cannot
use blacklist to disable the conflated model keypress event only on it.
This patch checks whether current or parent document is Confluence with JS
module, called KeyPressEventModelCheckerChild. For kicking this module,
nsHTMLDocument dispatches an custom event, CheckKeyPressEventModel, when it
becomes editable only first time. Finally, if it's a Confluence instance, the
module let PresShell know that we need to use split model keypress event in it.
Differential Revision: https://phabricator.services.mozilla.com/D17907
--HG--
extra : moz-landing-system : lando
Gecko Profiler uses DWARF information to get stack. But xptcall assembler for
Android/aarch64 doesn't have CFI directive, so it cannot walk stack well.
Differential Revision: https://phabricator.services.mozilla.com/D18335
--HG--
extra : moz-landing-system : lando
The total size of an IPC inputStream message must be less than 1mb. When we
compose the message for the multiplex stream, each sub stream collaborates with
its own size, deciding if it's better to be a pipe stream (IPCRemoteStream) or
a full serialized one.
Differential Revision: https://phabricator.services.mozilla.com/D18543
--HG--
extra : moz-landing-system : lando
It relies on AC_TRY_RUN, which doesn't work on cross-compiles. What this
means is that the feature has been disabled on mac builds on automation
ever since we switched to cross-compiles. It's still enabled on local
mac builds because the test runs there, and returns "yes". It also means
it's disabled on Android, where it probably works (at least debug tests
on try don't complain).
It also doesn't currently run on Windows because it's in a skipped
section on Windows, but if moved out of that section, the test returns
"no".
So, we remove any configure test for the feature, in favor of
preprocessor checks in nsTraceRefcnt.cpp.
Depends on D18055
Differential Revision: https://phabricator.services.mozilla.com/D18056
--HG--
extra : moz-landing-system : lando
Found when forcing a non-unified build of the Gecko Profiler:
- "nsError.h" needed to define `nsresult`.
- "nsStringFwd.h" needed to declare `nsAString` and `nsACString`.
Differential Revision: https://phabricator.services.mozilla.com/D18621
--HG--
extra : moz-landing-system : lando
The only difference between ShutdownLoaders and ShutdownFinal was an observer service shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D18389
--HG--
extra : moz-landing-system : lando
Give nsIStringStream separate SizeOfIncludingThisIfUnshared and SizeOfIncludingThisEvenIfShared methods. Use the former for memory reporting and the latter for JS engine memory accounting.
Differential Revision: https://phabricator.services.mozilla.com/D29336
We already take steps in `IndexOf` to avoid bounds checks--by using
direct pointer accesses--and we should do the same thing for binary
searches as well.
ProcessTypeRequiresWinEventHook was added when attempting to turn on win32k
lockdown for GMP processes. Having a less specific, but globally accessible,
function will make it more useful while applying win32k lockdown to other
process types.
Before this set of patches, the decision of exposing the stream as a pipe was
centralized in IPCStreamUtils, based on the total expectation size of the IPC
message. This triggers issues when multiplex inputStreams contain something
that cannot be sent as a pipe (IPCBlobInputStream, for instance), or something
that it's better to do not set as a pipe (nsFileInputStream), together with
memory streams (nsStringInputStream), which could make the IPC message greater
then what accepted (1mb).
These patches move the "pipe vs non-pipe" choice into the single inputStream
implementation.
In order to test the test harness's handling of a process failing to
produce a leak log, add a special function that disables the bloat log
output.
Differential Revision: https://phabricator.services.mozilla.com/D17534
--HG--
extra : moz-landing-system : lando
Don't warn about measurements that aren't available for the current platform.
Differential Revision: https://phabricator.services.mozilla.com/D17862
--HG--
extra : moz-landing-system : lando
This changes the policy to use the pref and permissions rather than a boolean flag. Using permissions gets us proper settings on startup without introducing any new overhead. Going this way flips our tests around so rather than testing an override to turn off private browsing support, we test overrides to enable private browsing support.
Differential Revision: https://phabricator.services.mozilla.com/D14482
--HG--
extra : moz-landing-system : lando
This patch removes the datetimebox binding and always use
UA Widget for the job.
Depends on D17571
Differential Revision: https://phabricator.services.mozilla.com/D17572
--HG--
extra : moz-landing-system : lando
This patch removes the XBL videocontrols binding and make <video>
to always use the UA Widget to generate controls.
DevTools tests that look for NAC is switched to use <input type=file>.
Differential Revision: https://phabricator.services.mozilla.com/D17571
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
We lose some sugar but gain some safety. This seems like the right
trade. If people want sugar they should use Rust.
Differential Revision: https://phabricator.services.mozilla.com/D16918
--HG--
extra : moz-landing-system : lando
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
Just because we're calling into the component manager for a service
doesn't mean that we're on a thread that has an associated event loop to
spin. If we are lacking such an event loop, we shouldn't try to
NS_ProcessNextEvent, because that will wind up asserting that there's no
event queue. Instead, just yield with the expectation that some other
thread is making progress on constructing the service that we want.
I'm always forgetting which code path is which. So give both these
functions clearer names that say if they're used by profiling or telemetry.
--HG--
extra : rebase_source : 8edcabba510bcf7170b7e071f7cb3a21be23b0e4
This is a better place for it and is more appropriate given that it
already exports to mozilla/DataMutex.h. I'll fix the rvalue reference
problems in a follow up.
Differential Revision: https://phabricator.services.mozilla.com/D16723
--HG--
rename : dom/media/eme/DataMutex.h => xpcom/threads/DataMutex.h
extra : moz-landing-system : lando
This patch implements -moz-gtk-csd-hide-titlebar-by-default media query
to check if the system titlebar should be disabled by default on Linux systems
(it's already disabled on Window/Mac).
It also removes explicit definition of browser.tabs.drawInTitlebar preference on Linux.
When browser.tabs.drawInTitlebar is missing the -moz-gtk-csd-hide-titlebar-by-default
is used to obtain the titlebar state. When browser.tabs.drawInTitlebar is set
in about:config or by Customize menu, the user peference is used instead of the default.
It also fixes a -moz-gtk-csd-available media query,
it was always true regardless the actual system setting.
Differential Revision: https://phabricator.services.mozilla.com/D16036
--HG--
extra : moz-landing-system : lando
This patch implements -moz-gtk-csd-hide-titlebar-by-default media query
to check if the system titlebar should be disabled by default on Linux systems
(it's already disabled on Window/Mac).
It also removes explicit definition of browser.tabs.drawInTitlebar preference on Linux.
When browser.tabs.drawInTitlebar is missing the -moz-gtk-csd-hide-titlebar-by-default
is used to obtain the titlebar state. When browser.tabs.drawInTitlebar is set
in about:config or by Customize menu, the user peference is used instead of the default.
It also fixes a -moz-gtk-csd-available media query,
it was always true regardless the actual system setting.
Differential Revision: https://phabricator.services.mozilla.com/D16036
--HG--
extra : moz-landing-system : lando
Currently nsAppRunner is responsible for choosing or creating a profile to use
at startup. It then has to create a reset profile if necessary and lock the
selected profile directories. But these latter things are done in different
places of the selection code and done in different ways, sometimes we delay
while trying to get the lock, sometimes we don't.
This patch moves the profile selection part of the code to its own function so
that then we only have to have one place that does the profile reset and
locking logic.
It makes a lot of sense to have the selection code live in the profile service.
It can use information from the database load to help make the choices and it
also means that we can expose the profile selection code through xpcom allowing
it to be easily automatically tested. It will also be more important for future
patches for the dedicated profiles feature.
Differential Revision: https://phabricator.services.mozilla.com/D16116
--HG--
extra : moz-landing-system : lando
To setup memory reporter on socket process, this patch modifies the PSocketProcess protocol to implement the same memory reporting functions as the PContent and PGPU protocols.
Differential Revision: https://phabricator.services.mozilla.com/D14155
--HG--
extra : moz-landing-system : lando
AsyncWaitRunnable holds a strong reference to its stream, and
NonBlockingAsyncInputStream holds a strong reference to the
runnable. The cycle gets broken in the RunAsyncWaitCallback() method
of the stream, but if the runnable is cancelled then we leak them
both. This patch fixes that by clearing the pointer to the stream when
the runnable is cancelled, breaking the cycle.
Differential Revision: https://phabricator.services.mozilla.com/D16248
--HG--
extra : moz-landing-system : lando
AsyncWaitRunnable holds a strong reference to its stream, and
NonBlockingAsyncInputStream holds a strong reference to the
runnable. The cycle gets broken in the RunAsyncWaitCallback() method
of the stream, but if the runnable is cancelled then we leak them
both. This patch fixes that by clearing the pointer to the stream when
the runnable is cancelled, breaking the cycle.
Differential Revision: https://phabricator.services.mozilla.com/D16248
--HG--
extra : moz-landing-system : lando
To setup memory reporter on socket process, this patch modifies the PSocketProcess protocol to implement the same memory reporting functions as the PContent and PGPU protocols.
Differential Revision: https://phabricator.services.mozilla.com/D14155
--HG--
extra : moz-landing-system : lando
The only visible change from this change is that telemetry will be
discontinuous. The owners for the relevant telemetry probes have
reviewed this and indicated that this discontinuity is OK.
The static XPCOM manifest format makes it easy to define a component in a
single place, without separate contract ID and CID macro definitions in
headers, and variable constants in module files. Without any other changes,
however, those macros are still required in order to create instances of or
retrieve services for the component.
This patch solves that problem by allowing component definitions to include an
explicit component name, and adding helpers for each named component to
Components.h:
mozilla::components::<Name>::CID() to retrieve its class ID.
mozilla::components::<Name>::Create() to create a new instance.
mozilla::components::<Name>::Service() to retrieve its service instance.
These getters have the benefit of doing full compile-time sanity checking,
with no possibilty of using a mistyped contract ID string, or a macro constant
which has gotten out of sync with the component entry.
Moreover, when possible, these getters are optimized to operate on module
entries directly, without going through expensive hash lookups or virtual
calls.
Differential Revision: https://phabricator.services.mozilla.com/D15037
--HG--
extra : rebase_source : ab07ef6a7ad8b26cd4e1901d3365beeb8c22ec3b
extra : source : 929fd654c9dfc3222e1972faadea3cc066e51654
We have tons of code in the component manager which stringifies nsIDs so that
it can print the result. The standard stringification process is pretty
bloated, and makes the code difficult to update. And, frankly, I mostly just
got tired of copying it around.
This patch adds a helper which stringifies a nsID to a nsAutoCString, which
can be used as a temporary value in a single statement, rather than requiring
a separate local variable and function call for each operation.
Differential Revision: https://phabricator.services.mozilla.com/D15036
--HG--
extra : rebase_source : 98dbd9dfa78b2f9d5cdab48e1c61e085bf7081c9
extra : source : 1ddd80d9e91a17c01f0a8a73036810042a0ab080
This patch essentially creates a separate, static component database for
statically-defined CID and contract ID entries, and gives it precedence over
the runtime DB. It combines the two separate databases by updating existing
code to use lookup functions which understand both databases, and then access
all entries through wrappers which defer to the appropriate underlying type.
Static component entries require no runtime relocations, and require no
writable data allocation aside from one pointer-sized BSS entry per CID, and
one bit of BSS per contract ID.
To achieve this, all strings in the static lookup tables are stored as indexes
into a static string table, all constructor functions live in a switch
statement which compiles to a relative jump table, and all writable data for
static entries is accessed by indexed lookups into BSS arrays.
We also avoid creating nsIFactory entries for static components when possible
by adding a CreateInstance method to nsFactoryEntry and the corresponding
entry wrapper to directly call the appropriate constructor method, and only
create a factory object when required by external code.
Differential Revision: https://phabricator.services.mozilla.com/D15035
--HG--
extra : rebase_source : 903a6f31c6290d0090e6765e0e317d1f749c5855
extra : source : b8d2dfdfc324c53ce5aacc822ce52d4e2bfdc31a
The static XPCOM manifest format makes it easy to define a component in a
single place, without separate contract ID and CID macro definitions in
headers, and variable constants in module files. Without any other changes,
however, those macros are still required in order to create instances of or
retrieve services for the component.
This patch solves that problem by allowing component definitions to include an
explicit component name, and adding helpers for each named component to
Components.h:
mozilla::components::<Name>::CID() to retrieve its class ID.
mozilla::components::<Name>::Create() to create a new instance.
mozilla::components::<Name>::Service() to retrieve its service instance.
These getters have the benefit of doing full compile-time sanity checking,
with no possibilty of using a mistyped contract ID string, or a macro constant
which has gotten out of sync with the component entry.
Moreover, when possible, these getters are optimized to operate on module
entries directly, without going through expensive hash lookups or virtual
calls.
Differential Revision: https://phabricator.services.mozilla.com/D15037
--HG--
extra : rebase_source : db7fe00fe80677a6a42d8136fd4505a02e330495
extra : absorb_source : ec11e22825befcd6fa4e96ffa81cd1c1b23e3bef
extra : histedit_source : 650e8e98235df5d757f3fa725bad390e9c094c34
We have tons of code in the component manager which stringifies nsIDs so that
it can print the result. The standard stringification process is pretty
bloated, and makes the code difficult to update. And, frankly, I mostly just
got tired of copying it around.
This patch adds a helper which stringifies a nsID to a nsAutoCString, which
can be used as a temporary value in a single statement, rather than requiring
a separate local variable and function call for each operation.
Differential Revision: https://phabricator.services.mozilla.com/D15036
--HG--
extra : rebase_source : 4a1971289bbf6abb42da30d024b30a81f7a0ca06
extra : absorb_source : 11318729edd01e7fc6bdbcc66346fdbf23e385ba
extra : histedit_source : c9a16f6e23c391813cfc3ce3fc82c835db0c46d6
This patch essentially creates a separate, static component database for
statically-defined CID and contract ID entries, and gives it precedence over
the runtime DB. It combines the two separate databases by updating existing
code to use lookup functions which understand both databases, and then access
all entries through wrappers which defer to the appropriate underlying type.
Static component entries require no runtime relocations, and require no
writable data allocation aside from one pointer-sized BSS entry per CID, and
one bit of BSS per contract ID.
To achieve this, all strings in the static lookup tables are stored as indexes
into a static string table, all constructor functions live in a switch
statement which compiles to a relative jump table, and all writable data for
static entries is accessed by indexed lookups into BSS arrays.
We also avoid creating nsIFactory entries for static components when possible
by adding a CreateInstance method to nsFactoryEntry and the corresponding
entry wrapper to directly call the appropriate constructor method, and only
create a factory object when required by external code.
Differential Revision: https://phabricator.services.mozilla.com/D15035
--HG--
extra : rebase_source : 8d02ff3b67b8078d1ac837d8c12f54786155c6b6
extra : absorb_source : 0fe36ca220c9270e634abf5b1f320a01878e0ce7
extra : histedit_source : 51521ceae2c1b3e4e8bf63d4ed1e2e67e9468780
Currently, when we build the component registry at startup, we exclude any
entry with a process selector which doesn't match the current process. When we
switch to static lookup tables, however, that check is going to have to happen
for every lookup, since we can't alter the table at runtime.
That may not matter much, given how expensive the rest of the component lookup
code is relative to ProcessMatchesSelector, but it's also easy and cheap
enough to generate a lookup table for all possible ProcessSelector values, and
do a quick index check instead.
Differential Revision: https://phabricator.services.mozilla.com/D15033
--HG--
extra : rebase_source : 33bb395f3eaa6522b18dbdb6e415b5287add86cd
extra : source : dd00365ebb55a06b4d6896bc86dd0fc94482d805
The current implementations of GetService are slightly different for contract
IDs than they are for CIDs, but I'm pretty sure that's unintentional.
This patch factors out the common parts of the two implementations, which
should prevent them from diverging in the future, and avoids the need to make
the same changes in multiple places in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D15032
--HG--
extra : rebase_source : fceab9df2879f8e02c81009ab3d8c754c9f14677
extra : source : 538e40c5ee1336a7ba467f0f4128dcddf97ef75d
Currently, when we build the component registry at startup, we exclude any
entry with a process selector which doesn't match the current process. When we
switch to static lookup tables, however, that check is going to have to happen
for every lookup, since we can't alter the table at runtime.
That may not matter much, given how expensive the rest of the component lookup
code is relative to ProcessMatchesSelector, but it's also easy and cheap
enough to generate a lookup table for all possible ProcessSelector values, and
do a quick index check instead.
Differential Revision: https://phabricator.services.mozilla.com/D15033
--HG--
extra : rebase_source : fa6c764c2acd68dbe620e5a0779c6c58724ea209
The current implementations of GetService are slightly different for contract
IDs than they are for CIDs, but I'm pretty sure that's unintentional.
This patch factors out the common parts of the two implementations, which
should prevent them from diverging in the future, and avoids the need to make
the same changes in multiple places in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D15032
--HG--
extra : rebase_source : 591d854d604dc7597dbfe5438bfbd0af98224c5b
nsTimerEvent goes through a multi-step initialization for reasons that
are lost to time. We are also seeing peculiar crashes in
`nsTimerEvent::SetTimer()` that are only explainable by `SetTimer`
finding a non-null pointer where there should have been a null pointer.
The compiler ought to have been able to optimize those bits away, but no
matter: we can do the job ourselves and make the code clearer.
Since we only call `SetTimer` once, we should just move its work into
nsTimerEvent's constructor.
Doing this code movement separately will ideally make the next part of
this work easier to review. The idea is that we want to extract all the
necessary information from `timer` before we pass ownership of it into
the newly-allocated nsTimerEvent.
Unlike many of our uses of `new`, nsTimerEvent has its own definition of
`operator new`, to ensure instances are allocated through
TimerEventAllocator. And allocating with TimerEventAllocator can fail.
Later changes, however, want to assume that constructing an nsTimerEvent
can't fail, which is difficult to guarantee with the current structure.
To make that guarantee, we need to make explicit what calling `new`
does: there's an "allocate memory" step and a "construct the object"
step. The first part can fail, and that's what we care about here.
Once we have a chunk of memory, we can construct the object as normal,
secure in the knowledge that calling (placement) `new` is now guaranteed
to succeed.
The layout module initializes a bunch of things, specifically
XPConnect. And if we're not loading chrome manifests, we shouldn't need
to initialize the layout module.
Checking that the current process type is not equal to some value
requires adding code when new process types are added. Since it seems
reasonable to assume that all new process types aren't going to require
chrome manifests, let's make the code reflect that assumption as well,
and reduce the number of places you need to touch when adding a new
process type.
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This will be needed for the next patches since the cast from nsIDocument* to
nsISupports* will become ambiguous, and I don't really want to replace all users
of nsCOMPtr<nsIDocument> with RefPtr.
We have ToSupports to handle this, so use it.
Differential Revision: https://phabricator.services.mozilla.com/D15350
This was necessary back when it still contained a lot of xpcom code, but
shouldn't be necessary now that it only contains two objects.
Differential Revision: https://phabricator.services.mozilla.com/D15168
--HG--
extra : moz-landing-system : lando
The VisualViewport events are all nice and shiny, but unfortunately not quite
what is needed for the session store.
Firstly, the spec wants the "scroll" event to be fired only when the *relative*
offset between visual and layout viewport changes. The session store however
records the absolute offset and as such is interested in when *that* changes.
Secondly, again as per the spec the events don't bubble, and with the default
DOMEventTargetHelper implementation they don't escape the VisualViewport during
capturing, either. This means that any event listener must be added directly on
the VisualViewport itself in order to capture any events.
This might have been intended because the events use the same names as the
normal "scroll"/"resize" events, and as such you cannot specify separate event
listeners for VisualViewport and non-VisualViewport "scroll" events if both
events end up being dispatched to the same element (you can only try to filter
after the fact by looking at the originalTarget of the event).
At the same time, the VisualViewport is attached to the inner Window, and so
each time you navigate, you also get a different VisualViewport object.
All of this might be totally fine from the perspective of a page script, because
in that case you won't care anyway about what happens when the current page goes
away.
From the session store perspective on the other hand (especially Fennec's non-
e10s session store design), this is rather unfortunate because we don't want to
have to keep registering event listeners
a) manually for each subframe
b) each time the page navigates
The event target chain problem could be solved by letting the scroll events
escape the VisualViewport during the capturing phase (which the spec doesn't say
anything about), but this would mean that any scroll listener attached to a
window/browser/... that uses capturing will now catch both layout and visual
viewport scroll events.
In some cases this might even be beneficial, but in others (e.g. bug 1498812
comment 21) I'd like to specifically decide which kind of scroll event to
capture. Having to look at event.originalTarget to distinguish the two kinds
might be defensible in test code, but in case this distinction would be needed
in production code as well, given the existence of a C++-based filtering helper
in nsSessionStoreUtils for another use case where (scroll) events need to be
filtered, JS-based scroll event filtering might be a bad idea.
Additionally, in any case this wouldn't solve the fundamental conflict between
the spec and the session store about *when* the "scroll" event should be fired
in the first place.
Hence I'd like to introduce a separate set of events with distinct event names,
which will be dispatched according to the requirements of our internal users
(i.e. currently the session store). To avoid potential web compatibility issues
down the road, for now these events will be dispatched only to event listeners
registered in the system group (allowing *all* Chrome event listeners cannot be
done because checking the Chrome status of each event target might be too
expensive for frequently dispatched events).
Differential Revision: https://phabricator.services.mozilla.com/D14046
--HG--
extra : moz-landing-system : lando
Move js/src/jsapi.h declarations related to promises and job queues into their
own public header file, js/public/Promise.h. Change the compilation units that
need these declarations to #include the new header.
There should be no changes to the actual functionality here, simply moving the
code to a new file, and removing the "JS" prefix from some typedefs which are
now in the JS namespace.
Differential Revision: https://phabricator.services.mozilla.com/D13345
--HG--
extra : moz-landing-system : lando
Fails with clang trunk:
"type of UTF-8 string literal will change from array of const char to array of const char8_t in C++2a"
otherwise
Differential Revision: https://phabricator.services.mozilla.com/D14696
--HG--
extra : moz-landing-system : lando
This backs out the main patch landed earlier in bug 1194856 and the
patch from bug 1225004.
Differential Revision: https://phabricator.services.mozilla.com/D14050
--HG--
extra : moz-landing-system : lando
vpx_mem_set_functions support is only enabled when
MOZ_VPX_NO_MEM_REPORTING is not set. It is currently set unconditionally
when building with the in-tree libvpx. When building with system libvpx,
it is set when the vpx_mem_set_functions can't be found in the system
libvpx library.
Upstream removed the vpx_mem_set_functions function in version 1.5, and
we require at least that version, meaning, in practice,
MOZ_VPX_NO_MEM_REPORTING is now always set.
We might as well remove the define and the code that's conditional to
not being defined.
Differential Revision: https://phabricator.services.mozilla.com/D14517
--HG--
extra : moz-landing-system : lando
David Major
Andrea Marchesini
Andrew McCreight
Jeff Walden
Razvan Maries
Gijs Kruitbosch
Aaron Klotz
Gurzau Raul
Alex Gaynor
Peter Van der Beken
Cosmin Sabou
Nika Layzell
Jed Davis
Honza Bambas
Nicholas Nethercote
Lina Cambridge
Nathan Froyd
Olli Pettay
Ryan Hunt
Karl Tomlinson
Andreea Pavel
Oana Pop Rus
Masayuki Nakano
Emilio Cobos Álvarez
Masatoshi Kimura
Makoto Kato
Bogdan Tara
Csoregi Natalia
Sylvestre Ledru
Coroiu Cristina
Markus Stange
Michael Cooper
Daniel Varga
Mike Hommey
Florian Quèze
Jim Blandy
Jonathan Kingston
Kris Maglione
Myk Melez
Adrian Wielgosik
Chris Peterson
arthur.iakab
Brian Hackett
Noemi Erli
Kirk Steuber
Boris Zbarsky
Ciure Andrei
Eric Rahm
Gerald Squelart
Jon Coppeard
shindli
Dave Townsend
Sebastian Hengst
Bob Owen
ffxbld
Randell Jesup
Dorel Luca
Dana Keeler
Shane Caraveo
Timothy Guan-tin Chien
James Willcox
Jeff Muizelaar
Greg Tatum
Martin Stransky
Andy Wingo
Ehsan Akhgari
Paul Bone
Henri Sivonen
Dragana Damjanovic
xftroxgpx
Brindusan Cristian
Kershaw Chang
Cameron McCormack
Jan de Mooij
bitnotri
Gabriele Svelto
quasicomputational
Michael Froman
Jan Henning
Jean-Yves Avenard