This refactors the observer service code to improve readability, uses MOZ_TRY
and other checking macros wherever possible to simplify error handling and
replaces the ObserverRef class with the more generic nsMaybeWeakPtr class.
This cuts away some code and halves the amount of memory needed to store an
event listener. The external behavior is almost unchanged save for some error
codes which are now more specific.
Differential Revision: https://phabricator.services.mozilla.com/D11646
--HG--
extra : source : 10d910aa9f31435116a718bafe8a2b71c61fe23d
Get an impersonation token for the user who started the maintenance service, use that when creating or moving files in user-controlled directories (currently only update.status). This token is passed along to the updater where it is used the same way (update.status, update log, and elevated lock file).
The workings of getting the token are in usertoken.cpp
Differential Revision: https://phabricator.services.mozilla.com/D7840
--HG--
extra : moz-landing-system : lando
These two interfaces are effectively never used, so to avoid needing to support
ClassID2JSValue with the new implementation, I remove them entirely.
Differential Revision: https://phabricator.services.mozilla.com/D2285
This adds a way to detect if an instance is holding a weak reference or a
strong one, makes non-critical failures less chatty and adds separate methods
for adding unique and non-unique instances to an array.
Differential Revision: https://phabricator.services.mozilla.com/D11645
--HG--
rename : toolkit/components/places/nsMaybeWeakPtr.h => xpcom/base/nsMaybeWeakPtr.h
extra : moz-landing-system : lando
Potentially, if the watcher notification task failed to dispatch, we would have a cycle left between the WatchManager and the OwnerType
Differential Revision: https://phabricator.services.mozilla.com/D11857
--HG--
extra : moz-landing-system : lando
This adds a new class for the marquee tag, instead of overloading HTMLDivElement.
It removes some of the XBL that was used to expose properties to web content.
Differential Revision: https://phabricator.services.mozilla.com/D3824
--HG--
extra : moz-landing-system : lando
TSan doesn't support std::atomic_thread_fence, so in order to avoid noisy
output, we can replace the fence with an atomic load when building with
-fsanitize=thread. This is a better alternative than error message
suppression since it's closer to the relevant code and thus much likelier
to survive changes to it.
Differential Revision: https://phabricator.services.mozilla.com/D11803
--HG--
extra : moz-landing-system : lando
And thus massively speed up ascii-case-insensitive atom comparisons when both
atoms are lowercase (which is the common case by far).
This removes almost all the slow selector-matching in this page, and it seems
an easier fix than storing the lowercased version of all class-names in quirks
mode in elements and selectors...
Differential Revision: https://phabricator.services.mozilla.com/D10945
--HG--
extra : moz-landing-system : lando
We only use its value in one place, and said value is easily computable
from readily available information. This change makes iterators
slightly smaller.
This is a rebase + manual refcounting on some places, + cleanup of the original
patch in the bug.
Co-authored-by: Nicholas Nethercote <nnethercote@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D11035
Other frames calling InitAndWrapInColumnSetFrameIfNeeded() needs to be
modified to support column-span (bug 1489295).
Depends on D5208
Differential Revision: https://phabricator.services.mozilla.com/D5209
--HG--
extra : moz-landing-system : lando
They're just integers, so there's no reason they need to be fallible
since they're basically a built-in anyways.
Differential Revision: https://phabricator.services.mozilla.com/D11363
--HG--
extra : moz-landing-system : lando
Move XUL persistence handling into it's own class and make it a separate
nsIDocumentObserver so it can also be used in non-XUL documents.
To avoid adding persistence to all non-XUL documents, a document must add
the "mozpersist" attribute to the root element if it wants enable the
feature.
Differential Revision: https://phabricator.services.mozilla.com/D6802
--HG--
extra : moz-landing-system : lando
Add CEnum types to XPIDL, allowing for typed enums in C++ instead of
using uintXX_t types. Javascript will still reflect CEnums as
interface level consts.
Depends on D8593
Differential Revision: https://phabricator.services.mozilla.com/D8594
--HG--
extra : moz-landing-system : lando
Sometimes when we call ShutdownWithTimeout on a thread pool, the unresponsive
thread that we leak will actually complete before the main thread is done.
In that case, the thread will dereference the thread shutdown context, so
we must intentionally leak it too.
Differential Revision: https://phabricator.services.mozilla.com/D10645
NsresultExt.to_result() is called by Rust code, so it would be more idiomatic for it to return Result<(), nsresult>, i.e. to return Ok(()) when the nsresult is NS_OK. This change makes it do so.
MozReview-Commit-ID: EaMEKfonHhC
Differential Revision: https://phabricator.services.mozilla.com/D10127
--HG--
extra : moz-landing-system : lando
After bug 1496622, the IDL parser converts some references to `nsresult` in IDL files to `::nserror::nsresult` in IDL-generated Rust files. But it doesn't convert others. It should convert them all consistently, and this patch makes it do so by adding conversion of the return type of attribute getters/setters and references generated by the IDL parser's Typedef class.
MozReview-Commit-ID: 838K8XGjvTx
Differential Revision: https://phabricator.services.mozilla.com/D10121
--HG--
extra : moz-landing-system : lando
This method is necessary because some threads might be stuck making blocking
calls. This means the thread is not processing any events, and we're unable
to safely terminate it. Our solution here is to leak the stuck threads
instead of waiting for them and potentially causing a shutdown hang.
Differential Revision: https://phabricator.services.mozilla.com/D9601
--HG--
extra : moz-landing-system : lando
This bumps the timeout when waiting for reports to 180 seconds which seems to
be long enough for MacOS in automation.
--HG--
extra : rebase_source : 6eb396e53bd37f6640b7c5402fb997c73af40d99
This is kind of like the previous patch (where we had a not-very-friendly user experience shutting down misbehaving h2 sessions), but in this case the server has proven to us that it can speak a minimum of h2, so we don't want to just fallback. Instead, when we send a GOAWAY frame because we have detected some error on the part of the server, if it's a top-level page load, we'll show an error page explaining that the server spoke bad http/2, and the site admin(s) need to be contacted. We already did this for INADEQUATE_SECURITY (which is its own special case still), but that didn't cover all the cases.
Differential Revision: https://phabricator.services.mozilla.com/D8436
--HG--
extra : moz-landing-system : lando
I left GetMethodInfo, GetConstant as they are still useful as separate methods.
Differential Revision: https://phabricator.services.mozilla.com/D9638
--HG--
extra : moz-landing-system : lando
This is needed for bug 1500926. It takes the approach of taking a JSFlatString
and using AutoAssertCannotGC to read the memory directly from the JS heap.
This lets us avoid re-encoding strings when performing lookups, which can be
advantageous.
Only ASCII strings are supported by this handler, and wide strings are hashed
as though they contain only values under 0x7f. This is OK as invalid keys to
perfecthash may return any hashtable entry.
Differential Revision: https://phabricator.services.mozilla.com/D9405
This commit adds a scroll origin, nsGkAtoms::relative, which can be used to
mark main thread scrolling that can be combined with a concurrent APZ scroll.
The behavior of this is controlled by a pref, apz.relative-update. This pref
is initially activated and is intended as an aid to narrowing down causes
of regressions for users in bug reports.
Relative scroll updates work by tracking the last sent or accepted APZ
scroll offset. This is sent along with every FrameMetrics. Additionally,
a flag is added to FrameMetrics, mIsRelative, indicating whether the
scroll offset can be combined with a potential APZ scroll. When this
flag is set, AsyncPanZoomController will apply the delta between the sent
base scroll offset, and sent new scroll offset.
This flag is controlled by the last scroll origin on nsGfxScrollFrame. The
new origin, `relative`, is marked as being able to clobber APZ updates,
but can only be set if all scrolls since the last repaint request or
layers transaction have been relative.
Differential Revision: https://phabricator.services.mozilla.com/D8234
--HG--
extra : rebase_source : 51351a84c9cda228a0975e22eda3fd3bd8d261c4
extra : histedit_source : 4b564c19b16fe2bd26adc671b62b7cb6106e8163
After the previous patches, we no longer rely on the component manager
to incidentally start up XPConnect when we load the JS loader service
or to hold the JS component loader alive, so the do_GetService() call
for the JS loader in XPCOMInit.cpp can be removed. After that is done,
the JS loader is no longer used as an XPCOM component, so all of the
boilerplate for that can be removed.
Depends on D8757
Differential Revision: https://phabricator.services.mozilla.com/D8758
--HG--
extra : moz-landing-system : lando
nsLayoutModule must be initialized in order to call into JS, but I
don't want to have to rely on calling a service in that
module. Instead, always initialize the module very early in component
manager initialization. This also makes initialization more
consistent, so things like errors in manifests won't affect when it
happens, which can result in different behavior in different builds.
I also made nsLayoutModule initialization infallible, because I can't
imagine that we can do much that is useful without it.
Another change I made is that gInitialized is set to true even in a
GPU process. This simplifies checking whether initialization has
happened already when we start up the layout module.
Differential Revision: https://phabricator.services.mozilla.com/D9583
--HG--
extra : moz-landing-system : lando
JSONWriter currently calls new and delete indirectly through mozilla::MakeUnique to allocate a buffer. Becuase of this, the methods of this class cannot be invoked within Spidermonkey due to https://searchfox.org/mozilla-central/source/config/check_vanilla_allocations.py#6-14. Therefore, JSONWriter needs an AllocPolicy template parameter so that the allocation and deallocation routines can be changed to match the JS AllocPolicy when invoked within SpiderMonkey.
Differential Revision: https://phabricator.services.mozilla.com/D7279
--HG--
extra : moz-landing-system : lando
This change applies to Windows only.
Firefox will need to migrate the directory from the old location to the new location. This will be done only once by setting the pref `app.update.migrated.updateDir2.<install path hash>` to `true` once migration has completed.
Note: The pref name app.update.migrated.updateDir has already been used, thus the '2' suffix. It can be found in ESR24.
This also removes the old handling fallback for generating the update directory path. Since xulrunner is no longer supported, this should no longer be needed. If neither the vendor nor app name are defined, it falls back to the literal string "Mozilla".
The code to generate the update directory path and the installation hash have been moved to the updatecommon library. This will allow those functions to be used in Firefox, the Mozilla Maintenance Service, the Mozilla Maintenance Service Installer, and TestAUSHelper.
Additionally, the function that generates the update directory path now has extra functionality. It creates the update directory, sets the permissions on it and, optionally, recursively sets the permissions on everything within.
This patch adds functionality that allows Firefox to set permissions on the new update directory on write failure. It attempts to set the permissions itself and, if that fails and the maintenance service is enabled, it calls into the maintenance service to try from there. If a write fails and the permissions cannot be fixed, the user is prompted to reinstall.
Differential Revision: https://phabricator.services.mozilla.com/D4249
--HG--
rename : toolkit/mozapps/update/updater/win_dirent.cpp => toolkit/mozapps/update/common/win_dirent.cpp
rename : toolkit/mozapps/update/tests/unit_aus_update/cleanupSuccessLogMove.js => toolkit/mozapps/update/tests/unit_aus_update/updateDirectoryMigrate.js
extra : moz-landing-system : lando
Now that the XPCOM component loader infrastructure has stopped
pretending to support other file extensions, this intermediate
interface is no longer needed.
Depends on D8171
Differential Revision: https://phabricator.services.mozilla.com/D8172
--HG--
extra : moz-landing-system : lando
JS is the only file extension actually supported, and there are a few
layers of cruft that can be eliminated if we specialize it.
This eliminates one XPCOM registration of the JS component loader.
Depends on D8170
Differential Revision: https://phabricator.services.mozilla.com/D8171
--HG--
extra : moz-landing-system : lando
This allows some code to be deleted, including a KnownModule ctor.
Depends on D8168
Differential Revision: https://phabricator.services.mozilla.com/D8169
--HG--
extra : moz-landing-system : lando
Instead of creating a timer and then setting the timer's target, we can
determine the timer's target and pass it in directly when the timer is
created. This reordering of steps is slightly more efficient, since
SetTarget() is both a virtual call and requires locking, both of which
can be skipped if we know the target at timer creation time. If we're
reusing the timer, we also don't need to repeatedly set the timer's
target: we can set the target once at timer creation, and then be done.
We can do this safely here because mTaskCategory doesn't change
throughout the life of the IdleTaskRunner; we make mTaskCategory `const`
to make this more explicit to the reader.
There is no advantage in making these methods more restrictive on their
parameters than AssignLiteral.
The current implementation of the AppendLiteral overloads for equivalent
char_types is more permissive than AssignLiteral, but comments in the
implementation mention the possible optimization used in AssignLiteral and so
are assuming a similar constant and static storage duration restriction on its
parameter. The optimization may never be implemented, but clients that would
benefit from support for non-constant or non-static parameters are also
expected to be rare, so there is little value in ruling out the optimization
at this stage.
ReplaceLiteral currently uses the AssignLiteral optimization.
Differential Revision: https://phabricator.services.mozilla.com/D8777
--HG--
extra : moz-landing-system : lando
A character array initialized with a list of character literals will not
necessarily have a trailing null-terminator required for AssignLiteral or
trimmed in EqualsLiteral.
Depends on D8775
Differential Revision: https://phabricator.services.mozilla.com/D8951
--HG--
extra : moz-landing-system : lando
"Bound" is the term used in the C++ standard to describe the number of
elements in an array.
EqualsLiteral has no opportunity to optimize for constant and static storage
duration parameters.
Depends on D8773
Differential Revision: https://phabricator.services.mozilla.com/D8774
--HG--
extra : moz-landing-system : lando
There is no advantage in AssignASCII() for char, and AssignASCII() does not
exist for char16_t array and char_type. Similarly for ReplaceASCII and
AppendASCII. This AssignLiteral() overload already says it is not only for
ASCII.
Depends on D8771
Differential Revision: https://phabricator.services.mozilla.com/D8773
--HG--
extra : moz-landing-system : lando
Simplify the content sandbox policy by removing APP_BINARY_PATH and APP_DIR Mac sandbox parameters and their associated rules in the policy. Keep APP_PATH which is a parent directory of APP_BINARY_PATH and APP_DIR. Change APP_PATH to be the path to the parent process .app directory and make GetAppPath return this path when called from the parent or a child process.
Depends on D6717
Differential Revision: https://phabricator.services.mozilla.com/D6719
--HG--
extra : moz-landing-system : lando
Since https://hg.mozilla.org/mozilla-central/rev/9db7cf4cc385#l13.44 the type
system always excludes calls with character pointers and so there is no need
to mention this in the comment.
The comment for the 8-bit to 16-bit AssignLiteral overload is modified a
little to use "char" instead of "character" so as not to imply that anything
other than 8-bit char parameters may be provided to that overload.
The ReplaceLiteral and InsertLiteral comments are adjusted to use "character"
instead of "char" so as not to imply that the method or comment is limited to
8-bit char parameters.
Differential Revision: https://phabricator.services.mozilla.com/D8770
--HG--
extra : moz-landing-system : lando
In the current code there are 3 main issues:
1. nsFileStream is not really thread-safe. There is nothing to protect the
internal members and we see crashes.
2. nsPipeInputStream doesn't implement ::Seek() method and that caused issues
in devtools when a nsHttpChannel sends POST data using a pipe. In order to fix
this, bug 1494176 added a check in nsHttpChannel: if the stream doesn't
implement ::Seek(), let's clone it. This was an hack around nsPipeInputStream,
and it's bad.
3. When nsHttpChannel sends POST data using a file stream, nsFileStream does
I/O on main-thread because of the issue 2. Plus, ::Seek() is called on the
main-thread causing issue 1.
Note that nsPipeInputStream implements only ::Tell(), of the nsISeekableStream
methods. It doesn't implement ::Seek() and it doesn't implement ::SetEOF().
With this patch I want to fix point 2 and point 3 (and consequentially issue 1
- but we need a separate fix for it - follow up). The patch does:
1. it splits nsISeekableStream in 2 interfaces: nsITellableStream and
nsISeekableStream.
2. nsPipeInputStream implements only nsITellableStream. Doing this, we don't
need the ::Seek() check for point 2 in nsHttpChannel: a simple QI check is
enough.
3. Because we don't call ::Seek() in nsHttpChannel, nsFileStream doesn't do I/O
on the main-thread, and we don't crash doing so.
The NS_NewTimer* family of functions, when using a custom event target,
currently go through a path that looks something like:
auto timer = createTimer()
timer->SetTarget(target);
// call the requisite Init* function
return timer;
This setup is inefficient, because SetTarget requires the timer mutex to
be acquired. The mutex acquisition here is completely unnecessary,
because the timer hasn't yet been shared out to the wider world; we can
set the timer target without acquiring the mutex at all because we know
that no sharing is possible at this point.
This patch reworks things somewhat to make that possible.
In FxAccountsComponents.manifest, the previous line registers the
component CID, but only for the main process. This means we hit an
error while parsing the manifest in the child process, because the CID
is not recognized. The fix is simply to not try to use the CID to
register the contract in the child process.
As for the rest of the changes, since bug 1438688, XPT information is
compiled into the Firefox binary, so the interfaces manifest entry is
no longer needed. This patch removes instances of this line from
manifest files. This makes some manifest files empty, so the patch
also removes the now-empty files.
Differential Revision: https://phabricator.services.mozilla.com/D8751
--HG--
extra : moz-landing-system : lando
Sometimes the protocol buffer data (RiceEncodingData) sent by Google's Safe Browsing server has the following properties:
1. |has_first_value| is false
2. |num_entries| > 0
In this case, we can still parse the data and apply partial update correctly by assuming that the first value is equal to 0.
Differential Revision: https://phabricator.services.mozilla.com/D6393
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
Simplify the content sandbox policy by removing APP_BINARY_PATH and APP_DIR Mac sandbox parameters and their associated rules in the policy. Keep APP_PATH which is a parent directory of APP_BINARY_PATH and APP_DIR.
Depends on D6717
Differential Revision: https://phabricator.services.mozilla.com/D6719
--HG--
extra : moz-landing-system : lando
The creation of a new index or an object store may trigger a
ConstraintError if any of those elements already exists. Unfortunately,
the information provided by the ConstraintError is not enough to
determine the conditions that triggered the error.
This patch overrides the generic ConstraintError message with more
specific information about the duplicated index or object store.
Specifically:
- nsICSSAnonBoxPseudo --> nsCSSAnonBoxPseudoStaticAtom
- nsICSSPseudoElement --> nsCSSPseudoElementStaticAtom
The `nsI` prefix isn't necessary because these are no longer XPIDL types, and
the `StaticAtom` suffix makes their meaning clearer.
--HG--
extra : rebase_source : b68dd7c73f5036dcd6be4c3700b757441f59f9f2
This is the same as the other patch, except that it is applied to the
case where the QI returns an nsresult.
In addition, I marked the WithError helper class as being stack-only.
Depends on D7553
Differential Revision: https://phabricator.services.mozilla.com/D7554
--HG--
extra : moz-landing-system : lando
This patch adds a static assert to enforce that do_QueryInterface is
not used to go from a class to a base class, because that can be done
more efficiently via a static_cast. This is done by putting the type
of the source into the nsQueryInterface type. Once that is done, it is
easy to check the source and destination type. This has to be done
carefully so that in non-DEBUG builds, where NSCAP_FEATURE_USE_BASE is
defined, we don't generate any additional code.
The first step is to rename nsQueryInterface to
nsQueryInterfaceISupports. In DEBUG builds, I then add a new subtype
nsQueryInterface<T>, where T is the type of the object we are going to
QI. This class is a thin wrapper around nsQueryInterfaceISupports that
only forwards operations to the base class.
The main bit of trickery here is PointedToType<T>, which is needed to
get the type parameter for nsQueryInterface. This dereferences the
type, gets the address of it, then does RemovePointer. This is needed
because a wide variety of pointer types are passed in to
do_QueryInterface, including RefPtr<>, nsCOMPtr<>, raw pointers, and
OwningNonNull<>. PointedToType<RefPtr<T>> is equal to T,
PointedToType<T*> is equal to T, and so on.
In NSCAP_FEATURE_USE_BASE builds (opt), we only use
nsQueryInterfaceISupports, but in debug builds we use
nsQueryInterface<> where possible. The latter is also used for the
nsCOMPtr<nsISupports> overload, because we can always QI to
nsISupports, because that is sometimes used for canonicalization.
Another gross bit is that Assert_NoQueryNeeded can no longer use
nsCOMPtr<>, because it works by QIing T to T, which is banned by the
static analysis. Instead I had to reimplement it by hand.
Depends on D7527
Differential Revision: https://phabricator.services.mozilla.com/D7553
--HG--
extra : moz-landing-system : lando
This saves one word per static atom, per process.
The `nsGkAtoms` change is only a small part of this commit.
In regen_atoms.py:
- There is now only one link name per platform: nsGkAtoms::sAtoms[].
- But there is a new constant per atom, giving the index into
nsGkAtoms::sAtoms[].
- And the `atom!` macro for each atom indexes into nsGkAtoms::sAtoms[] using
the index constant.
- A couple of `*mut` pointers are now `*const`.
Elsewhere, the `(nsStaticAtom*)` casts within the `AppendElement()` calls are
necessary to avoid link errors, presumably due to some template instantiation
wrinkle.
--HG--
extra : rebase_source : 629642e708c8bc6e27d6057beae5f35955fdd837
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
This adds support for conversion from nsCOMPtr<A> to nsCOMPtr<B> when
A is a subclass of B. There's no reason to not allow this, and RefPtr
already supports this.
Differential Revision: https://phabricator.services.mozilla.com/D7226
--HG--
extra : moz-landing-system : lando
This adds support for conversion from nsCOMPtr<A> to nsCOMPtr<B> when
A is a subclass of B. There's no reason to not allow this, and RefPtr
already supports this.
Differential Revision: https://phabricator.services.mozilla.com/D7226
--HG--
extra : moz-landing-system : lando
If a class A is derived from a class B, then an instance of A can be
converted to an instance of class B via a static cast, so QI is not
needed. QIs are slower than static casts.
TestCallTemplates seems to be testing that CallQueryInterface compiles
even if the first argument's class is only ambiguously castable to
nsISupports, so I changed the second argument to be a class unrelated
to the concrete class.
I also removed some useless null checks on the return value of new.
Differential Revision: https://phabricator.services.mozilla.com/D6838
--HG--
extra : moz-landing-system : lando
Presumably the commit that introduced `aStringOffset` could have removed this,
but overlooked it.
--HG--
extra : rebase_source : 176f14ce01c18ed4c83892d2b7a9e7a54fb5c836
Static atom registration is a bit of a mess. NS_InitAtomTable() calls
nsGkAtoms::RegisterStaticAtoms(), which calls NS_RegisterStaticAtoms(); i.e. we
go from nsAtomTable.cpp to nsGkAtoms.cpp and back.
(And NS_RegisterStaticAtoms() is declared in a .cpp file, not a .h file!)
This commit makes NS_InitAtomTable() a friend of nsGkAtoms, so NS_InitAtomTable
can see nsGkAtoms's atoms array directly, thus removing the need for
NS_RegisterAtomTable() and nsGkAtoms::RegisterStaticAtoms().
This commit also removes an out-of-date part of a comment from XPCOMInit.cpp.
--HG--
extra : rebase_source : 7e1f9aa0a9f7cb5088159fe4c953948b931f6d68
nsGkAtoms.h has a big comment explaining how static atom definitions get
expanded by macros. This comment was very useful when there were multiple
sources of static atoms and their definitions used macros a lot. But bug
1482782 combined all the static atom sources into nsGkAtoms and removed a lot
of macro use. So now the comment is now something of a hindrance, duplicating
quite a bit of the code (and not entirely accurately).
This commit removes the big comment, and moves the still-useful parts inline
with the code. This makes things much easier to follow.
This commit also reformats some of the remaining macros so they are easier to
read.
--HG--
extra : rebase_source : 4377be2fa0edc4ea1f592985ded89acbb76fb104
In TestEventTargetQI.cpp, nsIThreadPool is a subclass of
nsIEventTarget, so we cannot QI from the former to the latter once
trivial QIs are banned. However, we still want to check if a QI to
nsIEventTarget does something, so I added an intermediate cast up to
nsISupports, and then QI from there. I wrapped that all up in a
templated function, because the code is a bit ugly, and used it
everywhere for uniformity, even though it is not always needed.
I fixed TestCOMPtr.cpp in the same way, by casting up to nsISupports.
Differential Revision: https://phabricator.services.mozilla.com/D6855
--HG--
extra : moz-landing-system : lando
This doesn't fix the problem, but at least moves the resulting assertion
closer to the problematic caller, and makes it easier to diagnose.
Differential Revision: https://phabricator.services.mozilla.com/D7042
--HG--
extra : rebase_source : 4a016d1dce77a269b886467c9343dab125079a8f
extra : amend_source : 4e9133e70932f382e0b5df9e487978b95d05781b
These maps hold strong references which complicate nsThread lifetime handling
considerably, and only have a couple of fringe uses. We have a linked list of
active threads that the thread manager can use for its internal enumeration
purposes, and the external uses are easily done away with, so there doesn't
seem to be much reason to keep the map around.
MozReview-Commit-ID: x7dsj6C4x8
--HG--
extra : source : 5f870621361012ba459943212d8c68a9ff81cb16
extra : intermediate-source : 89a0c0874d400dd324df6fc3627c0c47d130df19
extra : histedit_source : bbd7900e3d754bde925a411c10aa30a1d6e22edd
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : source : a03a61d6d724503c3b7c5e31fe32ced1f5d1c219
extra : intermediate-source : 5152af6ab3e399216ef6db8f060c257b2ffbd330
extra : histedit_source : ef06000344416e0919f536d5720fa979d2d29c66%2C4671676b613dc3e3ec762edf5d72a2ffbe6fca3f
These maps hold strong references which complicate nsThread lifetime handling
considerably, and only have a couple of fringe uses. We have a linked list of
active threads that the thread manager can use for its internal enumeration
purposes, and the external uses are easily done away with, so there doesn't
seem to be much reason to keep the map around.
MozReview-Commit-ID: x7dsj6C4x8
--HG--
extra : rebase_source : 897e2d32d1dfee24d51459065925fb9b41fa543a
extra : source : 5f870621361012ba459943212d8c68a9ff81cb16
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : rebase_source : fcf8fa50e748c4b54c3bb1997575d9ffd4cbaae1
extra : source : a03a61d6d724503c3b7c5e31fe32ced1f5d1c219
These maps hold strong references which complicate nsThread lifetime handling
considerably, and only have a couple of fringe uses. We have a linked list of
active threads that the thread manager can use for its internal enumeration
purposes, and the external uses are easily done away with, so there doesn't
seem to be much reason to keep the map around.
MozReview-Commit-ID: x7dsj6C4x8
--HG--
extra : rebase_source : 88c56fa4f5da97f33ade08d892c3d8c42666307e
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : rebase_source : 02c5572b92ee48c11697d90941336e10c03d49cf
Replace mozilla.widget.use-argb-visuals pref by -moz-gtk-csd-transparent-background media query at browser.css
to draw transparent background. The media query is set by toolkit code and enabled when compatible
window manager is detected.
Differential Revision: https://phabricator.services.mozilla.com/D6658
--HG--
extra : moz-landing-system : lando
Gabriele Svelto
Razvan Maries
Boris Zbarsky
Adam Gashlin
Ted Campbell
Andreea Pavel
Nika Layzell
Alex Gaynor
Gurzau Raul
Cameron McCormack
Jean-Yves Avenard
arthur.iakab
Blake Kaplan
Michael Froman
Coroiu Cristina
Brian Grinstead
Bogdan Tara
Yaron Tausky
Sylvestre Ledru
Emilio Cobos Álvarez
Eric Rahm
Yoshi Huang
Ciure Andrei
Philip Chimento
Nathan Froyd
Andrea Marchesini
Dorel Luca
Ting-Yu Lin
Kyle Machulis
Csoregi Natalia
Brendan Dahl
Ehsan Akhgari
Narcis Beleuzu
shindli
Gerald Squelart
Valentin Gosu
Brian Hackett
arno renevier
Cosmin Sabou
Daosheng Mu
Kirk Steuber
Myk Melez
Nicholas Hurley
Adrian Wielgosik
Ryan Hunt
Andrew McCreight
Noemi Erli
Denis Palmeiro
Jim Blandy
Sebastian Hengst
ffxbld
Karl Tomlinson
Haik Aftandilian
Mark Banner
André Bargull
Jonathan Kingston
A. Wilcox
Henri Sivonen
Dimi Lee
Mats Palmgren
Stephen A Pohl
David Parks
Randell Jesup
Diego Pino Garcia
Nicholas Nethercote
Tim Nguyen
Jonathan Watt
Brindusan Cristian
Jonathan Kew
Kris Maglione
Jon Coppeard
Martin Stransky