Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
nsTSubstring::Split used to heap-allocate an array to store all tokens.
However, most uses of Split just use it to iterate in a range-based for loop.
The few remaining uses also don't need to iterate multiple times over all
tokens, so it's better to just use nsTokenizedRange, which tokenizes lazily.
Differential Revision: https://phabricator.services.mozilla.com/D99234
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
There are no uses of nsTCharSeparatedTokenizer that require run-time
configuration of the flags, so having them a compile-time template
argument allows for generation of more efficient code.
This might not matter that much now, but a subsequent patch will add another
flag to allow merging the implementation of nsTSubstring::Split with
nsTCharSeparatedTokenizer, through which the compile-time evaluation will
become more relevant.
Differential Revision: https://phabricator.services.mozilla.com/D99368
And have it mirror in the parent process more automatically.
The docShellIsActive setter in the browser-custom-element side needs to
be there rather than in the usual DidSet() calls because the
AsyncTabSwitcher code relies on getting an exact amount of notifications
as response to that specific setter. Not pretty, but...
BrowserChild no longer sets IsActive() on the docshell itself for OOP
iframes. This fixes bug 1679521. PresShell activeness is used to
throttle rAF as well, which handles OOP iframes nicely as well.
Differential Revision: https://phabricator.services.mozilla.com/D96072
This moves parts of IPCMessageUtils.h to two new header files and adapts
the include directives as necessary. The new header files are:
- EnumSerializer.h, which defines the templates for enum serializers
- IPCMessageUtilsSpecializations.h, which defines template specializations
of ParamTraits with extra dependencies (building upon both IPCMessageUtils.h
and EnumSerializer.h)
This should minimize the dependencies pulled in by every consumer of
IPCMessageUtils.h
Differential Revision: https://phabricator.services.mozilla.com/D94459
The resolver object held by DataResolver must be destroyed on the actor's worker
thread, as it holds non-threadsafe references.
Differential Revision: https://phabricator.services.mozilla.com/D97827
I was running into issues where these names would conflict with the type's own Get/Set methods
and these names have the added benefit of indicating a bit more that atomic stuff is going on.
Differential Revision: https://phabricator.services.mozilla.com/D99268
The DOM presentation tests require an implementation of
nsISocketTransport that doesn't actually implement anything,
for some reason.
Re-implementing that in C++ allows me to make nsISocketTransport
builtinclass.
Differential Revision: https://phabricator.services.mozilla.com/D98861
The DOM presentation tests require an implementation of
nsISocketTransport that doesn't actually implement anything,
for some reason.
Re-implementing that in C++ allows me to make nsISocketTransport
builtinclass.
Differential Revision: https://phabricator.services.mozilla.com/D98861
TSan found races on these flags that are ostensibly benign but this way there's no UB.
This code is a bit weird. These bitfields are seemingly pointless as
they're squeezed between a uint64_t and an Atomic<bool>. There's plenty
of space for 2 more bools there.
Also the Atomic<bool> could theoretically be merged into the flags. For
now, here's the version of this patch that preserves the semantics of
this code as closely as possible, for review by the code owners.
Differential Revision: https://phabricator.services.mozilla.com/D93416
TSan found races between mResolveAgain and mGetTtl. This makes them non-UB.
The code is a bit weird. Although the values are typed as uint16_t's, they're
used as bools (even assigned true/false). In addition, the atomic bool mTRRUsed
could be folded into these fields, as there is a spare bit. I decided not to
change these things, as network code can have weird representation requirements
that I'd prefer the owners of the code chime in on first.
Differential Revision: https://phabricator.services.mozilla.com/D93417
If there is still a listener remaining when the reference count drops to 0,
HttpChannelChild::Release() dispatches a runnable to call DoNotifyListener.
This runnable will get an additional reference to the channel.
However, stabilization has already occurred, even though we decided to
not destroy the object. We need to take care to release that reference
in order to prevent a leak.
Along similar lines, we should not call NS_LOG_RELEASE with 0 as the
refcount in this case, because the refcount is not yet 0. In order to
deal with this, I pushed the single NS_LOG_RELEASE into the various
cases and then changed the way it worked for the DoNotifyListener case.
Differential Revision: https://phabricator.services.mozilla.com/D98532
TSan found races on these flags that are ostensibly benign but this way there's no UB.
This code is a bit weird. These bitfields are seemingly pointless as
they're squeezed between a uint64_t and an Atomic<bool>. There's plenty
of space for 2 more bools there.
Also the Atomic<bool> could theoretically be merged into the flags. For
now, here's the version of this patch that preserves the semantics of
this code as closely as possible, for review by the code owners.
Differential Revision: https://phabricator.services.mozilla.com/D93416