This is more standard, and uses about 4kb less memory when almost empty,
which seems to be the common case in an idle content process. This should save
around 66kb per content process.
The next patch will get ride of this thin wrapper and use nsDataHashtable
directly.
Differential Revision: https://phabricator.services.mozilla.com/D76985
This method is the same as Put(), except that it asserts that the item
is not already present. It also puts the key second. Make it compatible
by hoisting out the assert and reversing the arguments. We can use the
definition of Put() defined in an earlier patch.
Differential Revision: https://phabricator.services.mozilla.com/D77167
nsTHashtable::Remove doesn't assert if the item isn't present. Match that
behavior by removing the assert and putting it at all of the call sites.
This just turns IDMap::Remove into RemoveIfPresent, so merge them.
Differential Revision: https://phabricator.services.mozilla.com/D77166
This function is similar to the Put() method in nsTHashtable, but it lists the
key second and it asserts that the key is not already in the map. This patch
swaps the arguments and hoists the assertion out, where appropriate. Note that
there are a few places that were working around this assert, so for those places
don't include the assert.
Differential Revision: https://phabricator.services.mozilla.com/D77165
GetConstructedEventTarget and GetSpecificMessageEventTarget always return
null. The idea was that subclasses could override them, but nobody does any
more.
Differential Revision: https://phabricator.services.mozilla.com/D76984
We are seeing crashes on aarch64 Fenix devices that appear to be related
to zero-sized messages. But we're seeing the crashes when we're trying
to send the messages on the IO thread, and not where we're dispatching
them from. Add some asserts so we get errors closer to the source, and
add some asserts for other things that we believe to be true and would
be useful to know aren't actually true.
Differential Revision: https://phabricator.services.mozilla.com/D76496
I don't think all this complexity is worth it for having a
marginally-more-realistic testing story. Using the pref just works and we should
do that, I think.
Differential Revision: https://phabricator.services.mozilla.com/D59980
This method always copies, and is redundant with the other getter methods on
IPDL unions. As there is only one caller, it can be removed to simplify the
code, and remove a source of complexity.
Differential Revision: https://phabricator.services.mozilla.com/D75349
Currently, the worker's COEP is saved in WorkerPrivate and not be respected when loading resources in workers.
This patch adds an attribute loadingEmbedderPolicy in nsILoadInfo, which indicates the COEP header the loading must be respected.
The default value of loadingEmbedderPolicy is nsILoadInfo::EMBEDDER_POLICY_NULL.
loadingEmbedderPolicy is initialized with the COEP of the BrowsingContext used for creating LoadInfo.
And it could be set to other value when fetch in workers.
Differential Revision: https://phabricator.services.mozilla.com/D73690
In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75371
We add a 'IsThirdPartyContextToTopWindow' flag in the LoadInfo. This
flag shows if the channel is considered as a third party related to the
top-level window.
This flag would be set when opening the channel in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D73199
Fix intermittent issues due to races.
We now run the MozPromise generated by the IPDL bindings to run their callbacks via a direct task dispatch.
This avoids a full trip to the back of the event queue for each additional asynchronous step when using MozPromise.
A consequence to this change is that each IPDL actor's thread must have an AbstractThread allocated if IPDL MozPromises are used.
It prevents unexpected racy behaviours when combining MozPromise with the other Resolve/Reject IPDL async declaration which was have lead to processing the events out of order.
Differential Revision: https://phabricator.services.mozilla.com/D71593
The hashes of certain strings is used indirectly in generating IDL C++ files. Before, we were using the `hash()` function to generate these hashes, which in Python 3 is non-deterministic over subsequent `python3` processes, causing bugs like bug 1635755. Instead, use a specific, deterministic hash to avoid spurious diff failures.
The `md5` hash function isn't completely cryptographically secure but the security of the hashes isn't important for us in this case since we're just using them as a per-string identifier. We could use a more robust hash function but there may be performance implications from doing so.
Differential Revision: https://phabricator.services.mozilla.com/D74446
`ply`, [by design](https://github.com/dabeaz/ply/issues/79), does not produce reproducible table files; hence bug 1633156. (Note that this was *always* true, but only became a problem once we switched to Python 3, which has more unpredictable dict iteration order than Python 2.7, at least prior to [3.7](https://docs.python.org/3/whatsnew/3.7.html#summary-release-highlights).)
In any other circumstance I would consider submitting a patch to `ply` to fix this, but as of the [in-progress version 4.0 of the library](https://github.com/dabeaz/ply/blob/master/CHANGES), it doesn't even emit this cached data any more, and indeed the [latest version of the code](1fac9fed64/ply) doesn't even call `open()` at all except to do logging or to read the text data to be parsed from `stdin`. So if we were going to pin our future on `ply` and upgrade to later versions of the library in the future, we would have to live in a world where `ply` doesn't generate cached table files for us anyway.
Emitting the cached table files so later build steps can consume them is an "optimization", but it's not clear exactly how much actual value that optimization provides overall. Quoth the `CHANGES` file from that repository:
```
PLY no longer writes cached table files. Honestly, the use of
the cached files made more sense when I was developing PLY on
my 200Mhz PC in 2001. It's not as much as an issue now. For small
to medium sized grammars, PLY should be almost instantaneous.
```
In practice, I have found this to be true; namely, `./mach build pre-export export` takes just about as long on my machine after this patch as it did before, and in a try push I performed, there's no noticeable performance regression from applying this patch. In local testing I also found that generating the LALR tables in calls to `yacc()` takes about 0.01s on my machine generally, and we generate these tables a couple dozen times total over the course of the `export` tier now. This isn't *nothing*, but in my opinion it's also not nearly long enough where it would be a concern given how long `export` already takes.
That `CHANGES` file also stresses that if caching this data is important, we have the option of doing so via `pickle`. If and when we decide that re-enabling this optimization is valuable for us, we should take control of this process and perform the generation in such a way that we can guarantee reproducibility.
Differential Revision: https://phabricator.services.mozilla.com/D73484
Currently, there is an outstanding issue where enabling the GPU sandbox breaks
scrolling using the the mouse wheel on laptops with Intel GPUs.
This will enable the GPU sandbox on Nightly for non-Intel GPUs to prevent any
sandbox regressions while we try and figure out what the scrolling issue is.
See Bug 1630860 for more info
Differential Revision: https://phabricator.services.mozilla.com/D73923
Adds IpdlQueue capability to PWebGL actors. The WebGLChild, used in content processes, implements SyncProducerActor and AsyncConsumerActor because it sends (sync and async) messages and receives responses to them that it reads as async messages. The WebGLParent, used in the compositor process, is a SyncConsumerActor and AsyncProducerActor for dual reasons.
Differential Revision: https://phabricator.services.mozilla.com/D68264
We need to separate WebGL actor construction and initialization since IpdlQueue initialization needs the actor to already exist.
Differential Revision: https://phabricator.services.mozilla.com/D68262
When the browser process starts a sandbox process, we copy the executable's IAT
for ntdll.dll into the new process to prevent DLL injection via IAT tampering as
the launcher process does. However, if IAT has been modified by a module injected
via `SetWindowHookEx`, the browser process cannot copy IAT because a modified IAT
is invalid in a different process, failing to start any sandbox processes.
The proposed fix is to cache IAT before COM initialization which may load
modules via `SetWindowHookEx` for the first time in the process.
Differential Revision: https://phabricator.services.mozilla.com/D73303
Adds IpdlQueue capability to PWebGL actors. The WebGLChild, used in content processes, implements SyncProducerActor and AsyncConsumerActor because it sends (sync and async) messages and receives responses to them that it reads as async messages. The WebGLParent, used in the compositor process, is a SyncConsumerActor and AsyncProducerActor for dual reasons.
Differential Revision: https://phabricator.services.mozilla.com/D68264
We need to separate WebGL actor construction and initialization since IpdlQueue initialization needs the actor to already exist.
Differential Revision: https://phabricator.services.mozilla.com/D68262
Both `nsAppShell::ProcessNextNativeEvent()` and `MessagePumpForUI::WaitForWork()` have a `PROFILER_AUTO_THREAD_SLEEP` surrounding the `mozilla::widget::WinUtils::WaitForMessage()` call.
However inside `WaitForMessage()` the call to `PeekMessageW()` may trigger a sequence of events (because the system delivers pending messages) that end in the initialization of a new thread, which invokes `ReentrantMonitor::Wait()` where there is a `PROFILER_AUTO_THREAD_SLEEP`.
To avoid this recursion, this patch moves `PROFILER_AUTO_THREAD_SLEEP` from both callers into `WaitForMessage()` to only enclose the actual potentially-sleeping operation `::MsgWaitForMultipleObjectsEx()`.
Differential Revision: https://phabricator.services.mozilla.com/D72850
When an Interceptor is marshaled for an external (non-chrome) process caller, we do not provide a handler and thus don't call HandlerProvider::WriteHandlerPayload.
However, GetMarshalSizeMax previously called HandlerProvider::GetPayloadSize even for external process callers.
For a11y's handlerProvider, we must build the payload to get the size.
This is wasteful in this case, since we're just going to throw it away.
Differential Revision: https://phabricator.services.mozilla.com/D72796
Because MainThreadHandoff sits between the Interceptor and the HandlerProvider, the caller must:
1. Get the event sink (the IInterceptorSink) from the Interceptor using IInterceptor::GetEventSink.
2. QI to the new IMainThreadHandoff interface. (An IInterceptorSink might not necessarily be a MainThreadHandoff.)
3. Get the HandlerProvider from the MainThreadHandoff using IMainThreadHandoff::GetHandlerProvider.
Differential Revision: https://phabricator.services.mozilla.com/D69484
This commit:
- removes sendRpcMessage, which was unused;
- removes the CPOW argument to sendAsyncMessage, broadcastAsyncMessage, and
sendSyncMessage;
- removes the aIsSync argument used internally to distinguish sendRpcMessage
and sendSyncMessage;
- removes CPOW tests;
- updates the few remaining callsites that use more than 2 arguments in
sendAsyncMessage for the removal of the cpows argument.
Differential Revision: https://phabricator.services.mozilla.com/D71514
Before 1496578, URIFixup::keywordToURI used to do a synchronous IPC call to be
able to access search engines from the content process. Consumers of URIFixup
didn't care. Bug 1496578 moved the IPC messaging to the callers, in particular
nsDocShell, but assumed nsDocShellLoadState wasn't loading from content.
It looks like in some cases it does, so this adds another sync IPC call for
GetFixupURIInfo.
The total numer of sync IPCs should not change from before Bug 1496578, URIFIxup
was just doing it internally, while now it happens at the call point.
Note the long term plan would be for these docshell objects callers to just
handle URIs, while the UI code should do fixup.
Bug 1375244 tracks the removal of these sync IPC messages.
Differential Revision: https://phabricator.services.mozilla.com/D70607
--HG--
extra : moz-landing-system : lando
It seems that all the warnings caused by the GPU sandbox have been fixed, and
the transparent window issue was resolved in D61370.
Hopefully there are no further complications and this can stay landed.
Differential Revision: https://phabricator.services.mozilla.com/D18876
--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
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--HG--
extra : moz-landing-system : lando
To be able to remove SystemGroup, NS_ReleaseOnMainThreadSystemGroup
needs to have its dependency on SystemGroup removed. Since all
releases using SystemGroup would've released on the main thread anyway
we can safely replace NS_ReleaseOnMainThreadSystemGroup with
NS_ReleaseOnMainThread.
Depends on D64390
Differential Revision: https://phabricator.services.mozilla.com/D67631
--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
When the GPU sandbox is enabled, access to most of the filesystem is blocked.
The GPU process uses a directory, "%profiledir%/shader-cache", to cache
compiled shared for performance reasons. Not allowing access to that directory
results in a HUGE performance backslide when the sandbox is turned on.
Differential Revision: https://phabricator.services.mozilla.com/D67893
--HG--
extra : moz-landing-system : lando
For Win32k lockdown, we need to remove the content processes' ability to
call GetICMProfileW(). Since it needs this to retrieve the output color
profile, a new synchronous call is added that allows it to request the
parent process to read this file on its behalf.
The contents of the file are now being cached as well, as this should help
ease some of the increased parent process I/O caused by the children not
being able to do this in their process anymore.
For performance reasons, during launch this information is passed directly
to the child through the SetXPCOMProcessAttributes call
Differential Revision: https://phabricator.services.mozilla.com/D66126
--HG--
extra : moz-landing-system : lando
No need for temporaries, we can just construct the object in place.
Depends on D69829
Differential Revision: https://phabricator.services.mozilla.com/D69830
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
No need for temporaries, we can just construct the object in place.
Depends on D69829
Differential Revision: https://phabricator.services.mozilla.com/D69830
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
When marshaling a11y calls from the content process, there are quite a lot of cross-thread QueryInterface calls (ipc::mscom::Interceptor::QueryInterfaceTarget).
Some of these are for special COM interfaces like IAgileObject and IFastRundown, which we could just special case in Interceptor::QueryInterface like we do for INoMarshal.
However, it seems there are a lot of other interfaces being queried and it's not clear why.
This patch adds a new HandlerProvider method: IsInterfaceMaybeSupported.
This allows implementations to indicate when there are interfaces which they definitely don't support, allowing the call to be answered without a cross-thread call.
Differential Revision: https://phabricator.services.mozilla.com/D69285
--HG--
extra : moz-landing-system : lando
We add a flag 'HasStoragePermission' in the LoadInfo. This flag
represents whether the loading document, for docuemnt loads, or the
loading resource has the storage permission. And this flag would only
get updated in the parent process when opening the channel.
Differential Revision: https://phabricator.services.mozilla.com/D67466
--HG--
extra : moz-landing-system : lando
This wasn't useful cross-platform.
ATK was the only consumer of this and it now uses ProxyAccessible::ChildAtPoint.
This also means the related aNeedsScreenCoords functionality in PDocAccessible::AccessibleAtPoint is no longer needed and has thus been removed.
Finally, this renames PDocAccessible::AccessibleAtPoint to PDocAccessible::ChildAtPoint for consistency with Accessible::ChildAtPoint now that the functionality is mirrored.
Differential Revision: https://phabricator.services.mozilla.com/D67987
--HG--
extra : moz-landing-system : lando
Also adds missing includes in some files, these were previously only transivitely
included through mozilla/TypeTraits.h.
Differential Revision: https://phabricator.services.mozilla.com/D68561
--HG--
extra : moz-landing-system : lando
For Win32k lockdown, we need to remove the content processes' ability to
call GetICMProfileW(). Since it needs this to retrieve the output color
profile, a new synchronous call is added that allows it to request the
parent process to read this file on its behalf.
The contents of the file are now being cached as well, as this should help
ease some of the increased parent process I/O caused by the children not
being able to do this in their process anymore.
For performance reasons, during launch this information is passed directly
to the child through the SetXPCOMProcessAttributes call
Differential Revision: https://phabricator.services.mozilla.com/D66126
--HG--
extra : moz-landing-system : lando
Previously, we only called AddTargetPeer() in
GeckoChildProcessHost::PerformAsyncLaunch() if the target process was not
sandboxed.
In the refactoring, the "else" clause was missed due to confusing CPP macros,
and now AddTargetPeer() is always called for non-plugin children.
This patch restores the old behavior of only calling AddTargetPeer() for non-
sandboxed processes.
Differential Revision: https://phabricator.services.mozilla.com/D67136
--HG--
extra : moz-landing-system : lando
This patch extends shared memory freezing to support the use case where
the parent process retains write access for incremental updates, while
other processes receive read-only access.
Note that, while some OSes allow independent read-only and read/write
capabilities for the same object, all we have on Android is an operation
that prevents future write mappings. Therefore, this allows an existing
writeable mapping to be retained, but if that is unmapped then even the
parent process can't re-create it.
As with freezing, the read-only restriction may not be enforceable if
the recipient process isn't adequately sandboxed (e.g., on Linux, if it
can use /proc/self/fd to reopen the inode for writing).
Differential Revision: https://phabricator.services.mozilla.com/D67187
--HG--
extra : moz-landing-system : lando
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
The fork server is not launched as expected with the
preference. This patch fix the issue.
Differential Revision: https://phabricator.services.mozilla.com/D65930
--HG--
extra : moz-landing-system : lando
Remove old content sandbox code paths that allowed the sandbox to be started
later during content process startup when the SetProcessSandbox() message was
received from the parent process. This older way of starting the sandbox was
still in the tree to support WebReplay which is now being removed. With this
fix, content processes always use the "earlyinit" sandbox startup like the
RDD and GMP processes.
Differential Revision: https://phabricator.services.mozilla.com/D64968
--HG--
extra : moz-landing-system : lando
Before this patch, PSM would register content type handlers to handle certain
certificate types. This was an easy way to install a client certificate after
generating a key with <keygen>, but keygen has been removed. This was also an
easy way to install root certificates, but that's actually a considerable
security risk. We kept this functionality for so long because it was the only
way to add a 3rd-party root certificate to Fennec's certificate store. Now that
Fennec is EOL, we can remove it. (Fenix will need a way to trust 3rd party root
certificates, but the path forward there is to implement the enterprise roots
feature for Android.)
Differential Revision: https://phabricator.services.mozilla.com/D66118
--HG--
extra : moz-landing-system : lando
For Win32k lockdown, we need to remove the content processes' ability to
call GetICMProfileW(). Since it needs this to retrieve the output color
profile, a new synchronous call is added that allows it to request the
parent process to read this file on its behalf.
The contents of the file are now being cached as well, as this should help
ease some of the increased parent process I/O caused by the children not
being able to do this in their process anymore.
Differential Revision: https://phabricator.services.mozilla.com/D66126
--HG--
extra : moz-landing-system : lando
Dictionary iteration under Python 3 is in an inherently unpredictable order, and while we try to keep DEFINES ordered through the use of OrderedDicts, if at any point we populate DEFINES directly or indirectly while iterating through the contents of a non-ordered dictionary, the order of the DEFINES (and therefore the contents of the output Makefile) will be nondeterministic as well. This patch makes a number of changes to ensure that we only ever populate DEFINES in a deterministic fashion. (Note that in Python 3.7 and later, the built-in dict class actually has deterministic ordering, so these changes are technically only necessary until our minimum Python version becomes 3.7.)
Differential Revision: https://phabricator.services.mozilla.com/D66089
--HG--
extra : moz-landing-system : lando
We were using the wrong Accessible method to get the level. We also need to swap IPDL methods to use the right one.
Differential Revision: https://phabricator.services.mozilla.com/D65645
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
Dictionary iteration under Python 3 is in an inherently unpredictable order, and while we try to keep DEFINES ordered through the use of OrderedDicts, if at any point we populate DEFINES directly or indirectly while iterating through the contents of a non-ordered dictionary, the order of the DEFINES (and therefore the contents of the output Makefile) will be nondeterministic as well. This patch makes a number of changes to ensure that we only ever populate DEFINES in a deterministic fashion. (Note that in Python 3.7 and later, the built-in dict class actually has deterministic ordering, so these changes are technically only necessary until our minimum Python version becomes 3.7.)
Differential Revision: https://phabricator.services.mozilla.com/D66089
--HG--
extra : moz-landing-system : lando
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
WalkHistoryEntries function gets called by nsSHistory::CloneAndReplaceChild
and nsSHistory::SetChildHistoryEntry recursively, so those have to be moved
into the parent process. This eliminates many sync IPC calls.
To facilitate transition to a new session history design,
we are mirroring mOSHE and mLSHE SH entries from docshell to browsing context.
Whenever we update those entries in docshell, we will also update those in BC,
and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D56201
--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
Apps targeting SDK 29 are not allowed to open /dev/ashmem directly, and
instead must use NDK functions. Those functions are only available in
SDK 26 and higher, so we need this shim to use the functions if they
are available, else fallback to opening /dev/ashmem directly.
Differential Revision: https://phabricator.services.mozilla.com/D61012
--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'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
We currently extract Document pointers from the old LoadInfo, and attach them to the new one, such that they aren't lost during serialization.
This moves us to setting them more directly from their original source, since the old LoadInfo is no longer reliable (and was only configured fully in the parent process).
Differential Revision: https://phabricator.services.mozilla.com/D64249
--HG--
extra : moz-landing-system : lando
We currently extract Document pointers from the old LoadInfo, and attach them to the new one, such that they aren't lost during serialization.
This moves us to setting them more directly from their original source, since the old LoadInfo is no longer reliable (and was only configured fully in the parent process).
Differential Revision: https://phabricator.services.mozilla.com/D64249
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
This removes `nsAutoPtr` usage from ipc/. security/ failed to build due to missing includes so I fixed that as well. IDB was using `ThreadLocal` from ipc which had a member changed to a `UniquePtr` so needed to be updated as well. localstorage was missing some includes.
Differential Revision: https://phabricator.services.mozilla.com/D63745
--HG--
extra : moz-landing-system : lando
We want to be able to send IPC messages from the translation in the parent. So
the simplest thing it move the top level actor parts of CanvasParent into
CanvasTranslator.
This patch also moves the canvas thread management parts out into a new
CanvasThreadHolder class and hopefully makes the lifecycle management of these
much more robust. This includes the use of a TaskQueue per CanvasTranslator to
manage serial processing on the canvas workers, instead of a boolean.
Differential Revision: https://phabricator.services.mozilla.com/D60887
--HG--
rename : gfx/layers/ipc/CanvasParent.cpp => gfx/layers/ipc/CanvasThread.cpp
rename : gfx/layers/ipc/CanvasParent.h => gfx/layers/ipc/CanvasThread.h
rename : gfx/layers/CanvasTranslator.cpp => gfx/layers/ipc/CanvasTranslator.cpp
rename : gfx/layers/CanvasTranslator.h => gfx/layers/ipc/CanvasTranslator.h
extra : moz-landing-system : lando
Andrew McCreight
Csoregi Natalia
Nika Layzell
Gian-Carlo Pascutto
Sylvestre Ledru
Gijs Kruitbosch
Nathan Froyd
Bob Owen
Chris H-C
Emilio Cobos Álvarez
Peter Van der Beken
Eden Chuang
nicolaspacheco
Aaron Klotz
Razvan Maries
Sebastian Streich
Bogdan Tara
Jean-Yves Avenard
Narcis Beleuzu
Tim Huang
ssengupta
Ricky Stewart
Chris Fronk
Kershaw Chang
Dorel Luca
Simon Giesecke
Chris Martin
David Parks
Toshihito Kikuchi
Daniel Varga
Gerald Squelart
James Teh
Stephen A Pohl
shravanrn@gmail.com
Makoto Kato
Brindusan Cristian
Chris Peterson
Marco Bonardo
Christoph Kerschbaumer
Andrea Marchesini
Cameron McCormack
Matt Woodrow
Gabriele Svelto
Andreas Farre
Frederik Braun
Cosmin Sabou
Jeff Walden
André Bargull
JulianWels
Oana Pop Rus
Bas Schouten
Jed Davis
Doug Thayer
Thinker Li
Kartikaya Gupta
Haik Aftandilian
JulianWels
Mihai Alexandru Michis
Noemi Erli
Dana Keeler
Ed Lee
Michael Froman
Eitan Isaacson
David Teller
Anny Gakhokidze
Jonathan Kew
Mark Banner
James Willcox
Jan Varga
Ciure Andrei
Coroiu Cristina
Eric Rahm