We go to great lengths to try to avoid initializing FrameLoaders during
document updates. That means that when `BindToTree` is called, the element's
FrameLoader is not initialized, and it has no BrowsingContext. Calling
`GetBrowsingContext()` (which happens as a side-effect of
`HTMLIFrameElement::RefreshFeaturePolicy`), however, forces eager
initialization, which can cause any number of problems.
This patch moves that logic from being triggered by `BindToTree` to being
triggered by `BrowsingContext::Embed`, which happens as soon as the
BrowsingContext is bound to the element, but does not force it to be created
early.
Differential Revision: https://phabricator.services.mozilla.com/D55872
--HG--
extra : moz-landing-system : lando
This patch removes the unnecessary getContentBlockingLog function from
nsIDocShell.idl.
Depends on D57464
Differential Revision: https://phabricator.services.mozilla.com/D57444
--HG--
extra : moz-landing-system : lando
* renames aboutNetworking.xhtml to aboutNetworking.html
* fixes markup to be valid html
* fixes missing instructions link in about:networking#logging
Differential Revision: https://phabricator.services.mozilla.com/D60814
--HG--
rename : toolkit/content/aboutNetworking.xhtml => toolkit/content/aboutNetworking.html
extra : moz-landing-system : lando
This patch removes the unnecessary getContentBlockingLog function from
nsIDocShell.idl.
Differential Revision: https://phabricator.services.mozilla.com/D57444
--HG--
extra : moz-landing-system : lando
I tested this by using delay(1) instead of delay(100), which reliably gives me
the "Is on an error page initially" failure without these changes and reliably
passs with them.
Differential Revision: https://phabricator.services.mozilla.com//D60345
--HG--
extra : histedit_source : e1c31b6183b569d7474af0de09292cc51635af5d
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
The intent of ConfigureChannel was to be code that needed to be applied to both the DocumentChannelChild in the content process, and the real channel in the parent.
It looks like everything in there is either QI'ing to a sub-type of channel (which won't apply to DocumentChannelChild), or is mutating the loadinfo/loadflags (which only need to be done once).
Differential Revision: https://phabricator.services.mozilla.com/D59264
--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
Depends on D47963
This workaround was only used by DevTools when using a chrome frame. DevTools toolbox now always uses frame type=content, so the workaround can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D47964
--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
Some notes about the changes:
Both test_bug384014.html and test_bug123696.html were testing reloading of
javascript: URI. The expected result of the iframes after reloading would
become about:blank. I deleted both file and instead wrote with
web-platform-test to cover reloading of javascript: URI since wpt is more
preferable.
storage-cache-error.html was utilizing javascript: URI to test bug 1262766.
javascript: URI would cause CacheStorage::Keys to throw a dom security
exception because the URI's principal (which did not match the principal of the
document in this case!) was a nullpricipal. With my patches the iframe's URL
would no longer be the javascript: URI, so it's no longer applicable for the
test case. Instead we can test what bug 1262766 was originally about - that
CacheStorage::Keys would throw a dom security exception if it's in a private
browsing window.
Differential Revision: https://phabricator.services.mozilla.com/D59465
--HG--
extra : moz-landing-system : lando
This shouldn't have any functional changes, and adds some new comments to explain the purpose of the classes a bit better.
Differential Revision: https://phabricator.services.mozilla.com/D59265
--HG--
rename : netwerk/ipc/DocumentChannelChild.cpp => netwerk/ipc/DocumentChannel.cpp
rename : netwerk/ipc/DocumentChannelChild.h => netwerk/ipc/DocumentChannel.h
extra : source : ca6f43c061311dfe3e45f0216e320872d9d62cd4
This shouldn't have any functional changes, and adds some new comments to explain the purpose of the classes a bit better.
Differential Revision: https://phabricator.services.mozilla.com/D59265
--HG--
rename : netwerk/ipc/DocumentChannelChild.cpp => netwerk/ipc/DocumentChannel.cpp
rename : netwerk/ipc/DocumentChannelChild.h => netwerk/ipc/DocumentChannel.h
extra : moz-landing-system : lando
Note that this also implicitly adds support for the view-source+srcdoc configuration, and setting of the BaseURI, which were both in the nsDocShell version but not the others.
Differential Revision: https://phabricator.services.mozilla.com/D57887
--HG--
extra : moz-landing-system : lando
Note that this also implicitly adds support for the view-source+srcdoc configuration, and setting of the BaseURI, which were both in the nsDocShell version but not the others.
Differential Revision: https://phabricator.services.mozilla.com/D57887
--HG--
extra : moz-landing-system : lando