Also logs JSWindowActor{Child,Parent}::Init and JSWindowActor::{Start,After}Destroy.
Differential Revision: https://phabricator.services.mozilla.com/D45346
--HG--
extra : moz-landing-system : lando
Adds GetManager on JSWindowActor (returns the associated WindowGlobalActor),
and IsInProcess on WindowGlobalActor (returns whether the actor is in process
or not).
Differential Revision: https://phabricator.services.mozilla.com/D57358
--HG--
extra : moz-landing-system : lando
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
--HG--
extra : moz-landing-system : lando
rg -l 'mozilla/Move.h' | xargs sed -i 's/#include "mozilla\/Move.h"/#include <utility>/g'
Further manual fixups and cleanups to the include order incoming.
Differential Revision: https://phabricator.services.mozilla.com/D60323
--HG--
extra : moz-landing-system : lando
We need to propagate `ContentParent::MarkAsDead` up to the Android java layer
so that it has a view of the state of content processes that is consistent
with the view of Gecko's content process management.
Differential Revision: https://phabricator.services.mozilla.com/D58564
--HG--
extra : moz-landing-system : lando
As each media controller corresponds to a tab (a browsing context tree), so the controller's life cycle should be equal to the tab. Currently we use the top-level browsing context to represent a tab, so when that browsing context is being destroyed, we should also destroy the corresponding media controller.
Therefore, `MediaControlService` don't need to have methods to access media controller anymore, we should access media controller directly from the top-level canonical browsing context.
Differential Revision: https://phabricator.services.mozilla.com/D58591
--HG--
extra : moz-landing-system : lando
To modify variable and function names to emphasize all media controllers added in the service are active controllers. If the controller doesn't have any controlled media, they won't be added into the service.
Differential Revision: https://phabricator.services.mozilla.com/D58589
--HG--
extra : moz-landing-system : lando
The assertion is added to diagnose whether NotifyContentBlockingEvent
will be called from an in-process document. We have already seen crashes
because of the assertion, so temporarily remove this to avoid people
keep crashing due to this.
Differential Revision: https://phabricator.services.mozilla.com/D60002
--HG--
extra : moz-landing-system : lando
This patch does the following:
1. Add a WindowGlobalChild IPC method - GetContentBlockingEvents. Documents can use the method
retrieve content blocking events stored in the parent process.
2. Update nsIDocShell::GetHasTrackingContentBlocked to return a promise.
3. Replace API in report-site-issue to use the promise-based GetHasTrackingContentBlocked API
Differential Revision: https://phabricator.services.mozilla.com/D56204
--HG--
extra : moz-landing-system : lando
1. Rename mCallerDocumentURI field of PostMessageEvent to mCallerURI as we
might not always have a document, e.g. when we have a sandbox.
2. When we neither have caller's inner window (and thus we have no caller's
window ID) nor caller's URI, use script location as a source name for the error
object when reporting errors to console.
3. When the caller of postMessage has its window in a different process, pass along
the caller's window ID so that the error can be reported correctly.
Differential Revision: https://phabricator.services.mozilla.com/D59526
--HG--
extra : moz-landing-system : lando
This allows us to access contentBlockingLog in the parent process
through a WindowGlobalParent object.
Differential Revision: https://phabricator.services.mozilla.com/D55779
--HG--
extra : moz-landing-system : lando
This allows us to access contentBlockingEvents in the parent process
through a WindowGlobalParent object.
Differential Revision: https://phabricator.services.mozilla.com/D55621
--HG--
extra : moz-landing-system : lando
The OnContentBlockingEvent is no longer needed once we make the
OnContentBlockingEvent parent only.
Differential Revision: https://phabricator.services.mozilla.com/D55788
--HG--
extra : moz-landing-system : lando
This patch adds an IPC message which allows content process to notify
the OnContentBlockingEvent in the parent process. This is needed because
there are some situations that the content blocking happens in content
processes, so we need to tell the parent process to notify it. Such as,
AntiTrackingCommon::AntiTrackingCommon::AddFirstPartyStorageAccessGrantedFor().
Differential Revision: https://phabricator.services.mozilla.com/D55648
--HG--
extra : moz-landing-system : lando
This patch makes the WindowGlobalParent to be able to send the
OnContentBlockingEvent in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D55645
--HG--
extra : moz-landing-system : lando
This adds a ContentBlockingLog into the WindowGlobalParent. This
ContentBlockingLog is bascially a copy of the log in the content
process. This log in parent is needed for the OnContentBlockingEvent in
parent process since we need an overview of the content blocking events
for OnContentBlockingEvent. And the ContentBlockingLog exits in the
content process in this stage, so we need to maintain a copy of it to
get the overview of the blocking events in parent.
Differential Revision: https://phabricator.services.mozilla.com/D54929
--HG--
extra : moz-landing-system : lando
Right now we do the same thing in two pretty different code paths... That's not
great, so unify them.
Differential Revision: https://phabricator.services.mozilla.com/D59629
--HG--
extra : moz-landing-system : lando
Right now we do the same thing in two pretty different code paths... That's not
great, so unify them.
Differential Revision: https://phabricator.services.mozilla.com/D59629
--HG--
extra : moz-landing-system : lando
This doesn't block the STATE_START notification from the new process, as we currently have a second start notification (when DocumentChannel redirects to the real channel), so this is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D56818
--HG--
extra : moz-landing-system : lando
Narcis Beleuzu
Andrea Marchesini
Kris Maglione
Mihai Alexandru Michis
Csoregi Natalia
Arnaud Renevier
Dimi Lee
Sylvestre Ledru
Razvan Maries
Frederik Braun
Kashav Madan
Emilio Cobos Álvarez
John Dai
Andreas Farre
Aaron Klotz
Valentin Gosu
Cosmin Sabou
Luca Greco
Zibi Braniecki
Jean-Yves Avenard
alwu
pbz
Anny Gakhokidze
David Teller
Eric Rahm
Tim Huang
Ciure Andrei
Matt Woodrow