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
