Currently, with Fission enabled we are not able to create a proper LoadInfo
object when doing a subdocument load because we do not have access to a loading
context if the load is happening inside of an OOP frame. To solve this problem,
we can create LoadInfo object from scratch in the parent process where we have
all of the required information.
Differential Revision: https://phabricator.services.mozilla.com/D68893
Currently, with Fission enabled we are not able to create a proper LoadInfo
object when doing a subdocument load because we do not have access to a loading
context if the load is happening inside of an OOP frame. To solve this problem,
we can create LoadInfo object from scratch in the parent process where we have
all of the required information.
Differential Revision: https://phabricator.services.mozilla.com/D68893
These properties used to be passed to newly created content windows in many
different ways, but are now unified under nsOpenWindowInfo. This patch cleans up
the remaining properties.
Differential Revision: https://phabricator.services.mozilla.com/D67056
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
Using the method name GetExistingCustomElements() to match CustomElements(), even though
they both return CustomElementRegistry.
Differential Revision: https://phabricator.services.mozilla.com/D69853
These properties used to be passed to newly created content windows in many
different ways, but are now unified under nsOpenWindowInfo. This patch cleans up
the remaining properties.
Differential Revision: https://phabricator.services.mozilla.com/D67056
I think I caught all the places in our tree that add event listeners for these
events on a non-Window (and hence depend on bubbling behavior), but I'm a
little worried about what happens if webextensions do bareword
addEventListener() for these events...
Differential Revision: https://phabricator.services.mozilla.com/D66798
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
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
The key here is to test the type of the variable declaration for being a
smartptr type, instead of testing the type of the variable _use_.
Differential Revision: https://phabricator.services.mozilla.com/D65581
We don't need to create the blocking-all cookieJarSettings every time we
request it since it is basically the same. Instead, we should make it as
a singleton.
The patch makes this change the rename the
CookieJarSettings::CreateBlockingAll() to GetBlockingAll() which
reflects the fact that it is a singleton.
Differential Revision: https://phabricator.services.mozilla.com/D64564
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
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
