This builds on the existing static components infrastructure to allow defining
a Services.jsm-type services cache with no runtime memory overhead for any
services until they're accessed.
Any class entry with a 'js_name' attribute automatically becomes available on
the services cache with that name, and any interfaces listed in its
'interfaces' list are automatically queried on it.
Differential Revision: https://phabricator.services.mozilla.com/D81417
CLOSED TREE
Backed out changeset 51d7c644a1e6 (bug 1650163)
Backed out changeset 3d2b6908447a (bug 1650163)
Backed out changeset 79141707d47b (bug 1650163)
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
The overall goal of this patch is to make the StartupCache accessible anywhere.
There's two main pieces to that equation:
1. Allowing it to be accessed off main thread, which means modifying the
mutex usage to ensure that all data accessed from non-main threads is
protected.
2. Allowing it to be accessed out of the chrome process, which means passing
a handle to a shared cache buffer down to child processes.
Number 1 is somewhat fiddly, but it's all generally straightforward work. I'll
hope that the comments and the code are sufficient to explain what's going on
there.
Number 2 has some decisions to be made:
- The first decision was to pass a handle to a frozen chunk of memory down to
all child processes, rather than passing a handle to an actual file. There's
two reasons for this: 1) since we want to compress the underlying file on
disk, giving that file to child processes would mean they have to decompress
it themselves, eating CPU time. 2) since they would have to decompress it
themselves, they would have to allocate the memory for the decompressed
buffers, meaning they cannot all simply share one big decompressed buffer.
- The drawback of this decision is that we have to load and decompress the
buffer up front, before we spawn any child processes. We attempt to
mitigate this by keeping track of all the entries that child processes
access, and only including those in the frozen decompressed shared buffer.
- We base our implementation of this approach off of the shared preferences
implementation. Hopefully I got all of the pieces to fit together
correctly. They seem to work in local testing and on try, but I think
they require a set of experienced eyes looking carefully at them.
- Another decision was whether to send the handles to the buffers over IPC or
via command line. We went with the command line approach, because the startup
cache would need to be accessed very early on in order to ensure we do not
read from any omnijars, and we could not make that work via IPC.
- Unfortunately this means adding another hard-coded FD, similar to
kPrefMapFileDescriptor. It seems like at the very least we need to rope all
of these together into one place, but I think that should be filed as a
follow-up?
Lastly, because this patch is a bit of a monster to review - first, thank you
for looking at it, and second, the reason we're invested in this is because we
saw a >10% improvement in cold startup times on reference hardware, with a p
value less than 0.01. It's still not abundantly clear how reference hardware
numbers translate to numbers on release, and they certainly don't translate
well to Nightly numbers, but it's enough to convince me that it's worth some
effort.
Depends on D78584
Differential Revision: https://phabricator.services.mozilla.com/D77635
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
The overall goal of this patch is to make the StartupCache accessible anywhere.
There's two main pieces to that equation:
1. Allowing it to be accessed off main thread, which means modifying the
mutex usage to ensure that all data accessed from non-main threads is
protected.
2. Allowing it to be accessed out of the chrome process, which means passing
a handle to a shared cache buffer down to child processes.
Number 1 is somewhat fiddly, but it's all generally straightforward work. I'll
hope that the comments and the code are sufficient to explain what's going on
there.
Number 2 has some decisions to be made:
- The first decision was to pass a handle to a frozen chunk of memory down to
all child processes, rather than passing a handle to an actual file. There's
two reasons for this: 1) since we want to compress the underlying file on
disk, giving that file to child processes would mean they have to decompress
it themselves, eating CPU time. 2) since they would have to decompress it
themselves, they would have to allocate the memory for the decompressed
buffers, meaning they cannot all simply share one big decompressed buffer.
- The drawback of this decision is that we have to load and decompress the
buffer up front, before we spawn any child processes. We attempt to
mitigate this by keeping track of all the entries that child processes
access, and only including those in the frozen decompressed shared buffer.
- We base our implementation of this approach off of the shared preferences
implementation. Hopefully I got all of the pieces to fit together
correctly. They seem to work in local testing and on try, but I think
they require a set of experienced eyes looking carefully at them.
- Another decision was whether to send the handles to the buffers over IPC or
via command line. We went with the command line approach, because the startup
cache would need to be accessed very early on in order to ensure we do not
read from any omnijars, and we could not make that work via IPC.
- Unfortunately this means adding another hard-coded FD, similar to
kPrefMapFileDescriptor. It seems like at the very least we need to rope all
of these together into one place, but I think that should be filed as a
follow-up?
Lastly, because this patch is a bit of a monster to review - first, thank you
for looking at it, and second, the reason we're invested in this is because we
saw a >10% improvement in cold startup times on reference hardware, with a p
value less than 0.01. It's still not abundantly clear how reference hardware
numbers translate to numbers on release, and they certainly don't translate
well to Nightly numbers, but it's enough to convince me that it's worth some
effort.
Depends on D78584
Differential Revision: https://phabricator.services.mozilla.com/D77635
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
The overall goal of this patch is to make the StartupCache accessible anywhere.
There's two main pieces to that equation:
1. Allowing it to be accessed off main thread, which means modifying the
mutex usage to ensure that all data accessed from non-main threads is
protected.
2. Allowing it to be accessed out of the chrome process, which means passing
a handle to a shared cache buffer down to child processes.
Number 1 is somewhat fiddly, but it's all generally straightforward work. I'll
hope that the comments and the code are sufficient to explain what's going on
there.
Number 2 has some decisions to be made:
- The first decision was to pass a handle to a frozen chunk of memory down to
all child processes, rather than passing a handle to an actual file. There's
two reasons for this: 1) since we want to compress the underlying file on
disk, giving that file to child processes would mean they have to decompress
it themselves, eating CPU time. 2) since they would have to decompress it
themselves, they would have to allocate the memory for the decompressed
buffers, meaning they cannot all simply share one big decompressed buffer.
- The drawback of this decision is that we have to load and decompress the
buffer up front, before we spawn any child processes. We attempt to
mitigate this by keeping track of all the entries that child processes
access, and only including those in the frozen decompressed shared buffer.
- We base our implementation of this approach off of the shared preferences
implementation. Hopefully I got all of the pieces to fit together
correctly. They seem to work in local testing and on try, but I think
they require a set of experienced eyes looking carefully at them.
- Another decision was whether to send the handles to the buffers over IPC or
via command line. We went with the command line approach, because the startup
cache would need to be accessed very early on in order to ensure we do not
read from any omnijars, and we could not make that work via IPC.
- Unfortunately this means adding another hard-coded FD, similar to
kPrefMapFileDescriptor. It seems like at the very least we need to rope all
of these together into one place, but I think that should be filed as a
follow-up?
Lastly, because this patch is a bit of a monster to review - first, thank you
for looking at it, and second, the reason we're invested in this is because we
saw a >10% improvement in cold startup times on reference hardware, with a p
value less than 0.01. It's still not abundantly clear how reference hardware
numbers translate to numbers on release, and they certainly don't translate
well to Nightly numbers, but it's enough to convince me that it's worth some
effort.
Depends on D78584
Differential Revision: https://phabricator.services.mozilla.com/D77635
The following telemetry probes have been replaced:
- GC_BUDGET_MS
- GC_MARK_ROOTS_MS
- GC_MARK_GRAY_MS
Depends on D82004
Differential Revision: https://phabricator.services.mozilla.com/D82005
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
The overall goal of this patch is to make the StartupCache accessible anywhere.
There's two main pieces to that equation:
1. Allowing it to be accessed off main thread, which means modifying the
mutex usage to ensure that all data accessed from non-main threads is
protected.
2. Allowing it to be accessed out of the chrome process, which means passing
a handle to a shared cache buffer down to child processes.
Number 1 is somewhat fiddly, but it's all generally straightforward work. I'll
hope that the comments and the code are sufficient to explain what's going on
there.
Number 2 has some decisions to be made:
- The first decision was to pass a handle to a frozen chunk of memory down to
all child processes, rather than passing a handle to an actual file. There's
two reasons for this: 1) since we want to compress the underlying file on
disk, giving that file to child processes would mean they have to decompress
it themselves, eating CPU time. 2) since they would have to decompress it
themselves, they would have to allocate the memory for the decompressed
buffers, meaning they cannot all simply share one big decompressed buffer.
- The drawback of this decision is that we have to load and decompress the
buffer up front, before we spawn any child processes. We attempt to
mitigate this by keeping track of all the entries that child processes
access, and only including those in the frozen decompressed shared buffer.
- We base our implementation of this approach off of the shared preferences
implementation. Hopefully I got all of the pieces to fit together
correctly. They seem to work in local testing and on try, but I think
they require a set of experienced eyes looking carefully at them.
- Another decision was whether to send the handles to the buffers over IPC or
via command line. We went with the command line approach, because the startup
cache would need to be accessed very early on in order to ensure we do not
read from any omnijars, and we could not make that work via IPC.
- Unfortunately this means adding another hard-coded FD, similar to
kPrefMapFileDescriptor. It seems like at the very least we need to rope all
of these together into one place, but I think that should be filed as a
follow-up?
Lastly, because this patch is a bit of a monster to review - first, thank you
for looking at it, and second, the reason we're invested in this is because we
saw a >10% improvement in cold startup times on reference hardware, with a p
value less than 0.01. It's still not abundantly clear how reference hardware
numbers translate to numbers on release, and they certainly don't translate
well to Nightly numbers, but it's enough to convince me that it's worth some
effort.
Depends on D78584
Differential Revision: https://phabricator.services.mozilla.com/D77635
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
The overall goal of this patch is to make the StartupCache accessible anywhere.
There's two main pieces to that equation:
1. Allowing it to be accessed off main thread, which means modifying the
mutex usage to ensure that all data accessed from non-main threads is
protected.
2. Allowing it to be accessed out of the chrome process, which means passing
a handle to a shared cache buffer down to child processes.
Number 1 is somewhat fiddly, but it's all generally straightforward work. I'll
hope that the comments and the code are sufficient to explain what's going on
there.
Number 2 has some decisions to be made:
- The first decision was to pass a handle to a frozen chunk of memory down to
all child processes, rather than passing a handle to an actual file. There's
two reasons for this: 1) since we want to compress the underlying file on
disk, giving that file to child processes would mean they have to decompress
it themselves, eating CPU time. 2) since they would have to decompress it
themselves, they would have to allocate the memory for the decompressed
buffers, meaning they cannot all simply share one big decompressed buffer.
- The drawback of this decision is that we have to load and decompress the
buffer up front, before we spawn any child processes. We attempt to
mitigate this by keeping track of all the entries that child processes
access, and only including those in the frozen decompressed shared buffer.
- We base our implementation of this approach off of the shared preferences
implementation. Hopefully I got all of the pieces to fit together
correctly. They seem to work in local testing and on try, but I think
they require a set of experienced eyes looking carefully at them.
- Another decision was whether to send the handles to the buffers over IPC or
via command line. We went with the command line approach, because the startup
cache would need to be accessed very early on in order to ensure we do not
read from any omnijars, and we could not make that work via IPC.
- Unfortunately this means adding another hard-coded FD, similar to
kPrefMapFileDescriptor. It seems like at the very least we need to rope all
of these together into one place, but I think that should be filed as a
follow-up?
Lastly, because this patch is a bit of a monster to review - first, thank you
for looking at it, and second, the reason we're invested in this is because we
saw a >10% improvement in cold startup times on reference hardware, with a p
value less than 0.01. It's still not abundantly clear how reference hardware
numbers translate to numbers on release, and they certainly don't translate
well to Nightly numbers, but it's enough to convince me that it's worth some
effort.
Depends on D78584
Differential Revision: https://phabricator.services.mozilla.com/D77635
This changes `HelperThreadTaskCallback` to be a `bool` type callback and changes `DispatchOffthreadTask` to return a bool type if `gHelperThreads` successfully dispatches. The failure will be `false` regardless of what kind of failure it is, but if JS doesn't care and only wants to know if there is a failure then this will be simpler than exposing a proper error enum. This also changes `HelperThreadPool::Dispatch` to no longer return `NS_OK` and instead returns whatever the `nsResult` from the nsThreadPool may be.
Differential Revision: https://phabricator.services.mozilla.com/D81770
We have a clang-plugin checker that wants to favor `SprintfLiteral` over `snprintf`, but for some reason it didn't catch this instance prior to clang-11.
Differential Revision: https://phabricator.services.mozilla.com/D80668
The changes in xpconnect are necessary because this is not being specified in
the usual way, with a getter. Ordinary data properties require an explicit
loophole to make them visible through X-ray wrappers.
Differential Revision: https://phabricator.services.mozilla.com/D77181
The 'asyncStack' flag on JS execution contexts is used as a general switch
to enable async stack capture across all locations in SpiderMonkey, but
this causes problems because it can at times be too much of a performance
burden to general and track all of these stacks.
Since the introduction of this option, we have only enabled it on Nightly
and DevEdition for non-mobile builds, which has left a lot of users unable
to take advantage of this data while debugging.
This patch enables async stack traces across all of Firefox, but introduces
a new pref to toggle the scope of the actual expensive part of async stacks,
which is _capturing_ them and keeping them alive in memory. The new pref
limits the capturing of async stack traces to only debuggees, unless an
explicit pref is flipped to capture async traces for all cases.
This means that while async stacks are technically enabled, and code could
manually capture a stack and pass it back to SpiderMonkey and see that stack
reflected in later captured stacks, SpiderMonkey itself and related async
DOM APIs, among others, will not capture stacks or pass them to SpiderMonkey,
so there should be no general change in performance by enabling the broader
feature itself, unless the user is actively debugging the page.
One effect of this patch is that if you have the debugger open and then close
it, objects that have async stacks associated with them will retain those
stacks and they will continue to show up in stack traces, no _new_ stacks
will be captured. jorendorff and I have decided that this is okay because
the expectation that the debugger fully revert every possible effect that it
could have on a page is a nice goal but not a strict requirement.
Differential Revision: https://phabricator.services.mozilla.com/D68503
The 'asyncStack' flag on JS execution contexts is used as a general switch
to enable async stack capture across all locations in SpiderMonkey, but
this causes problems because it can at times be too much of a performance
burden to general and track all of these stacks.
Since the introduction of this option, we have only enabled it on Nightly
and DevEdition for non-mobile builds, which has left a lot of users unable
to take advantage of this data while debugging.
This patch enables async stack traces across all of Firefox, but introduces
a new pref to toggle the scope of the actual expensive part of async stacks,
which is _capturing_ them and keeping them alive in memory. The new pref
limits the capturing of async stack traces to only debuggees, unless an
explicit pref is flipped to capture async traces for all cases.
This means that while async stacks are technically enabled, and code could
manually capture a stack and pass it back to SpiderMonkey and see that stack
reflected in later captured stacks, SpiderMonkey itself and related async
DOM APIs, among others, will not capture stacks or pass them to SpiderMonkey,
so there should be no general change in performance by enabling the broader
feature itself, unless the user is actively debugging the page.
One affect of this patch is that if you have the debugger open and then close
it, objects that have async stacks associated with them will retain those
stacks and they will continue to show up in stack traces, no _new_ stacks
will be captured. jorendorff and I have decided that this is okay because
the expectation that the debugger fully revert every possible effect that it
could have on a page is a nice goal but not a strict requirement.
Differential Revision: https://phabricator.services.mozilla.com/D68503
This renames the pref to remove 'experimental' and turns it on by default.
For integration with the CC, any DOM objects that are the target of a WeakRef or registered with a FinalizationRegistry have their wrappers preserved. WeakRef.deref() checks whether any wrapper is still preserved and returns undefined if not, to avoid giving out references to wrappers whose DOM object has been cycle collected.
Tests exercising browser integration are under js/xpconnect/tests/mochitest/.
Differential Revision: https://phabricator.services.mozilla.com/D77656
WeakRef targets that are wrappers to DOM objects are preserved when the WeakRef is created. This checks whether the wrapper is still preserved in deref() and if it is found to have been released, the target is cleared.
The patch adds a new DOMJSClass hook to deal with getting the wrapper cache for non-nsISupports objects.
Differential Revision: https://phabricator.services.mozilla.com/D78061
This adds an extra pref for whether the cleanupSome method is exposed and renames the existing pref. We can turn on the pref to expose cleanupSome to get test262 coverage in the browser.
Differential Revision: https://phabricator.services.mozilla.com/D77267
This makes is easier to actually assert that we have the right exception value.
We do have similar tests already, but most of them aren't based directly
on nsIScriptError.
Differential Revision: https://phabricator.services.mozilla.com/D74528
This was added for incremental sweeping of groups of zones (or compartments as they were then). This has been working fine for a long time and I don't think we need to continue collecting telemetry about it.
This leaves the data collection in place as it's still reported to the profile (which makes more sense I think).
Differential Revision: https://phabricator.services.mozilla.com/D75147
Doing this kind of censoring in "CreateScriptError" turns out to be more effort
than I thought. We don't have a JSContext to create Rooted instances.
This still catches all the relevant places where we are creating script-errors without inner-window-ids.
Differential Revision: https://phabricator.services.mozilla.com/D75152
We are adding support for the dotAll (/s) RegExp flag, so the list of expected properties on the RegExp prototype has to be updated.
Differential Revision: https://phabricator.services.mozilla.com/D74149
Implements the spec changes from: https://github.com/tc39/proposal-weakrefs/pull/187
The spec change removes the `FinalizationRegistryCleanupIterator` in favour of
calling the clean-up callback for each finalised value. It also allows to call
`cleanupSome()` within the callback function.
`FinalizationRegistryObject::cleanupQueuedRecords()` has been changed to iterate
from back to front, because this allows us to call `GCVector::popCopy()`, which
makes it more efficient to remove entries from the `records` vector.
Differential Revision: https://phabricator.services.mozilla.com/D70821
With the following changes Object.prototype.toString is not using the JSClass' name
anymore. This means we now fail to detect opaque wrappers, because they just get the default string: [object Object]
Differential Revision: https://phabricator.services.mozilla.com/D74016
We are adding support for the dotAll (/s) RegExp flag, so the list of expected properties on the RegExp prototype has to be updated.
Differential Revision: https://phabricator.services.mozilla.com/D74149
These pragmas can be used to influence stack trace filenames, and to affect
how and where files show up in developer tools. In some circumstances, it can
be nice to disable allof that functionality in order to ensure that you get
the stack trace and debug information as SpiderMonkey sees it.
Differential Revision: https://phabricator.services.mozilla.com/D72103
Instead of manually defining toStringTag we now add the toStringTag symbol to the list of properties.
This is also how we usually define toStringTag in the JS engine.
Even though this changes more code I like this approach better. Everything is centralized in the generated bindings file.
Differential Revision: https://phabricator.services.mozilla.com/D72179
We add a configuration option for SIMD and apply ENABLE_WASM_SIMD
throughout the engine as appropriate, mostly to insert #error or
MOZ_CRASH where things need to be done in later patches or for
architectures that we won't currently consider.
We add a command line switch for the shell and an option for
about:config and plumb the value of this through the engine.
Differential Revision: https://phabricator.services.mozilla.com/D57940
I am honstely still not convinced that this function should actually exists.
It seems like a convulted way of saying AtomToId, while also asserting that the atom is pinned.
Differential Revision: https://phabricator.services.mozilla.com/D72563
This requires adding a new JSOptions field (for internal use within the shell),
as well as a new browser pref (to support possible Cranelift benchmarking on
aarch64).
Differential Revision: https://phabricator.services.mozilla.com/D72907
In BrowsingContext::SetDocShell(), we indicate that any remote outer window
proxies need to be cleaned up, if we've transitioned from a remote window
proxy to a local one. However, we don't actually do the cleanup until
nsGlobalWindowOuter::SetNewDocument(), so don't assert if we find remote
window proxies when we're in between these two periods.
Also includes a formatting fix by clang-format.
Differential Revision: https://phabricator.services.mozilla.com/D72251
This patch introduces `nt::VirtualQuery` which consumes only ntdll's functions
to reduce dependency in `MMPolicy` on kernel32.dll. With this, `MMPolicy` still
depends on kernel32.dll, that will be solved by a coming patch.
Differential Revision: https://phabricator.services.mozilla.com/D68342
--HG--
extra : moz-landing-system : lando
This patch introduces `nt::VirtualQuery` which consumes only ntdll's functions
to reduce dependency in `MMPolicy` on kernel32.dll. With this, `MMPolicy` still
depends on kernel32.dll, that will be solved by a coming patch.
Differential Revision: https://phabricator.services.mozilla.com/D68342
--HG--
extra : moz-landing-system : lando
I think this was used when incremental GC was being enabled to see how whether/how frequently incremental GC got disabled. The data is a solid 0% for the last 15 versions at least.
Depends on D69826
Differential Revision: https://phabricator.services.mozilla.com/D69827
--HG--
extra : moz-landing-system : lando
We nuke xray waivers when we navigate outer windows out of process,
because it doesn't make much sense to have a waiver in that case.
This patch makes the behavior for navigating to local outer windows
consistent, by also nuking remote window proxies. Hopefully that
won't break anything.
This is Nightly-only for now, because it might break addons.
Differential Revision: https://phabricator.services.mozilla.com/D66495
--HG--
extra : moz-landing-system : lando
Xray waivers for remote window proxies don't make much sense, so we nuke any
waiver when a window proxy navigates from local to remote. However, this xray
waiver can be the target of a CCW, and dead wrappers are not supposed to the
target of a CCW, so we need to find and nuke any CCWs targetting the waiver.
This requires fixing js::RemapWrapper so that it can be used to fix CCWs to
dead wrappers.
Hopefully this will fix a bunch of intermittent failures in
browser_windowProxy_transplant.js.
Differential Revision: https://phabricator.services.mozilla.com/D66459
--HG--
extra : moz-landing-system : lando
This adds a JS shell command line argument to disable multi-value (if
it is enabled at compile time) and an about:config option to do the
same in the browser.
At this time, multi-values are not enabled in the browser, so the
about:config option is not visible.
Differential Revision: https://phabricator.services.mozilla.com/D67465
--HG--
extra : moz-landing-system : lando
I made some changes in preparation for removing nsIScriptError.flags in favor
of nsIConsoleMessage.logLevel.
Differential Revision: https://phabricator.services.mozilla.com/D66878
--HG--
extra : moz-landing-system : lando
I am not sure if you are okay with reviewing all those test changes.
Sadly it's not that easy to search through our huge JavaScript code
base for some generic name like 'isStrict'.
Differential Revision: https://phabricator.services.mozilla.com/D66573
--HG--
extra : moz-landing-system : lando
JSErrorFormatString::name should really be baked into the binary so we
don't need to do any memory management.
Differential Revision: https://phabricator.services.mozilla.com/D65828
--HG--
extra : moz-landing-system : lando
This patch partially implements `FileVersionInfoWin` and `base::FilePath` class of
Chromium sandbox so that a coming patch can use `base::win::OSInfo::Kernel32BaseVersion()`.
Differential Revision: https://phabricator.services.mozilla.com/D65744
The BindingCallContext tracks what method the conversion is for, and the source
description is how the primitive is involved in that method (e.g. "argument 5").
Differential Revision: https://phabricator.services.mozilla.com/D64887
--HG--
extra : moz-landing-system : lando
Dictionaries always need a BindingCallContext, because they can throw
MSG_NOT_DICTIONARY from Init().
We allow non-binding callsites to pass JSContext*, in which case they will not
get quite-as-nice error reporting.
Differential Revision: https://phabricator.services.mozilla.com/D64885
--HG--
extra : moz-landing-system : lando
The BindingCallContext tracks what method the conversion is for, and the source
description is how the primitive is involved in that method (e.g. "argument 5").
Differential Revision: https://phabricator.services.mozilla.com/D64887
--HG--
extra : moz-landing-system : lando
Dictionaries always need a BindingCallContext, because they can throw
MSG_NOT_DICTIONARY from Init().
We allow non-binding callsites to pass JSContext*, in which case they will not
get quite-as-nice error reporting.
Differential Revision: https://phabricator.services.mozilla.com/D64885
--HG--
extra : moz-landing-system : lando
Given that we are going to add ContentBlockingAllowList in
CookieSettings, so CookieSettings will be responsible for more stuff than the
cookie behavior and cookie permission. We should use a proper name to
reflect the purpose of it. The name 'CookieSettings' is misleading that
this is only for cookie related stuff. So, we decide to rename
'CookieSettins' to 'CookieJarSettings' which serves better meaning here.
Differential Revision: https://phabricator.services.mozilla.com/D63935
--HG--
rename : netwerk/cookie/CookieSettings.cpp => netwerk/cookie/CookieJarSettings.cpp
rename : netwerk/cookie/nsICookieSettings.idl => netwerk/cookie/nsICookieJarSettings.idl
extra : moz-landing-system : lando
We would before always prefer the error name and message contained in the JSErrorReport,
and that was probably ok, because ErrorReportToMessageString in xpc did basically the same thing as
ErrorReportToString in js. However now that we have special code to try and retrieve overwritten
name and message properties we need to prefer aToStringResult.
There was one caller in ContentUtils that explicitly passed "<unknown>" for aToStringResult,
all other callers either use nullptr or js::ErrorReport::toStringResult().c_str.
Differential Revision: https://phabricator.services.mozilla.com/D64350
--HG--
extra : moz-landing-system : lando
The method is exposed only if the consumer has the same principal as the PDF
would have if it were not getting the PDF viewer treatment.
The method just calls the print() method in the PDF viewer window.
It's enough to expose this on nsOuterWindowProxy, not RemoteOuterWindowProxy,
because PDF documents end up in the process they would have been in based on
their pre-PDF-viewer principal, since we do process determination in the parent
process but only run the pdfjs stream converter in the content process, once we
have decided which one to use.
Differential Revision: https://phabricator.services.mozilla.com/D63711
--HG--
extra : moz-landing-system : lando
The exception is not guaranteed to be in the context compartment anyway (e.g. changing the compartment does not wrap the exception), so there isn't much point checking it up front. And the exception stack is always stored as an unwrapped object, so again there's no point checking it on set, since we just plan to UncheckedUnwrap it.
Differential Revision: https://phabricator.services.mozilla.com/D64004
--HG--
extra : moz-landing-system : lando
This covers most cycle collected objects which support weak references, but
not the ones which inherit from a cycle collected class and don't do any cycle
collection on their own.
Differential Revision: https://phabricator.services.mozilla.com/D63962
--HG--
extra : moz-landing-system : lando
The method is exposed only if the consumer has the same principal as the PDF
would have if it were not getting the PDF viewer treatment.
The method just calls the print() method in the PDF viewer window.
It's enough to expose this on nsOuterWindowProxy, not RemoteOuterWindowProxy,
because PDF documents end up in the process they would have been in based on
their pre-PDF-viewer principal, since we do process determination in the parent
process but only run the pdfjs stream converter in the content process, once we
have decided which one to use.
Differential Revision: https://phabricator.services.mozilla.com/D63711
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
The default method implementations cause problems when trying to
override them with different types in a direct call class.
For the `Recv__delete__` case there's a simple solution: omit it if
there are any arguments, because it doesn't make much sense to specify
arguments and then completely ignore them, and the no-arg case isn't a
problem for overriding.
Differential Revision: https://phabricator.services.mozilla.com/D62977
--HG--
extra : moz-landing-system : lando
Because Tor disables both the Ion Jit and the Baseline Jit, we want
to enable both of them for trusted principals; not just Ion.
Differential Revision: https://phabricator.services.mozilla.com/D61272
--HG--
extra : moz-landing-system : lando
Now that JSScript and LazyScript share a trace method, we can use a single
TraceKind within the GC. To acheive this we also must remove eager marking of
LazyScripts.
Differential Revision: https://phabricator.services.mozilla.com/D62681
--HG--
extra : moz-landing-system : lando
This gives JSContext a more fine-grained view of which part of the GC is running on its thread, to separate out finalization from sweeping generally.
I had to remove an assertion in xpconnect which was the only place where this currently happened.
Differential Revision: https://phabricator.services.mozilla.com/D62453
--HG--
extra : moz-landing-system : lando
The debugger needs references to the DOM native functions for its whitelist
of pure functions that allow eager evaluation. These whitelist validations
can happen for many objects across many realms, so it is much easier if we
can pull these functions from a single central sandbox instead of trying to
pull them in from a specific content realm.
Differential Revision: https://phabricator.services.mozilla.com/D61964
--HG--
extra : moz-landing-system : lando
Because Tor disables both the Ion Jit and the Baseline Jit, we want
to enable both of them for trusted principals; not just Ion.
Differential Revision: https://phabricator.services.mozilla.com/D61272
--HG--
extra : moz-landing-system : lando
The browser is unable to start if this operation fails, but we should track
the difference between OOM and other forms of failure. This should now
classify OOM errors correctly in crash stats.
Differential Revision: https://phabricator.services.mozilla.com/D61779
--HG--
extra : moz-landing-system : lando
This will make the places we call ctors a little nicer, and the
extra flexibility is never used.
Differential Revision: https://phabricator.services.mozilla.com/D61329
--HG--
extra : moz-landing-system : lando
These methods used to do something interesting, but now they
are just wrappers around constructor calls.
This patch also gets rid of the default ctors that are "deleted"
by a comment. There's no need to delete them because we are already
defining a constructor, so no default constructor will be created.
Differential Revision: https://phabricator.services.mozilla.com/D61328
--HG--
extra : moz-landing-system : lando
This patch mainly enables the pref for SharedArrayBuffer on early Beta. (We have
already enabled that on Nightly by default)
This change causes some tests to fail. This patch handles the failures for
a mochitest and web-platform-tests.
Differential Revision: https://phabricator.services.mozilla.com/D60965
--HG--
extra : moz-landing-system : lando
It used to be that some XPIDL interfaces were allowed to be non-nsISupports,
and were only used to hold a bunch of constants. It appears that we've now
had enough de-COM work happen that there are no longer any, so we can remove
support for this.
Differential Revision: https://phabricator.services.mozilla.com/D61008
--HG--
extra : moz-landing-system : lando
For builtinclass interfaces, or ones not declared in IDL, we don't call out
into scripted QueryInterface anyway, so we can return earlier, before we ever
set up the AutoEntryScript.
Differential Revision: https://phabricator.services.mozilla.com/D61005
--HG--
extra : moz-landing-system : lando
It used to be that some XPIDL interfaces were allowed to be non-nsISupports,
and were only used to hold a bunch of constants. It appears that we've now
had enough de-COM work happen that there are no longer any, so we can remove
support for this.
Differential Revision: https://phabricator.services.mozilla.com/D61008
--HG--
extra : moz-landing-system : lando
It used to be that some XPIDL interfaces were allowed to be non-nsISupports,
and were only used to hold a bunch of constants. It appears that we've now
had enough de-COM work happen that there are no longer any, so we can remove
support for this.
Differential Revision: https://phabricator.services.mozilla.com/D61008
--HG--
extra : moz-landing-system : lando
Kris Maglione
Nika Layzell
Mihai Alexandru Michis
Doug Thayer
Narcis Beleuzu
Csoregi Natalia
ssengupta
Jon Coppeard
Noemi Erli
kriswright
Simon Giesecke
David Major
Nicholas Nethercote
Andrew McCreight
Jason Orendorff
Logan Smyth
Razvan Maries
Masatoshi Kimura
Andrea Marchesini
Tilden Windsor
Adam Vandolder
Gijs Kruitbosch
Tom Schuster
Frederik Braun
Tom Tung
Nicklas Boman
Iain Ireland
André Bargull
Dorel Luca
Sebastian Hengst
Yoshi Cheng-Hao Huang
Florian Quèze
Lars T Hansen
Benjamin Bouvier
Liang-Heng Chen
Cosmin Sabou
Emilio Cobos Álvarez
Toshihito Kikuchi
Andreas Farre
Daniel Varga
Jeff Walden
Eden Chuang
Marco Bonardo
Jim Porter
Bogdan Tara
Andreea Pavel
Boris Zbarsky
Ehsan Akhgari
Sebastian Streich
Arthur Iakab
Tim Huang
Andi-Bogdan Postelnicu
Ciure Andrei
Sylvestre Ledru
Jed Davis
Tom Ritter
Ted Campbell
shindli
J.C. Jones
Jan de Mooij
Jonathan Kingston
Olli Pettay
Brindusan Cristian