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
about:blank gets loaded into the new docshell before ResumeRedirectedLoad get called for the 'real' load
Under some circumstances, it is sometimes possible that we got far enough with the about:blank load to initialize a timing.
Under these conditions, it is safe to disregard the existing timing information and replace it with the one carried over.
Differential Revision: https://phabricator.services.mozilla.com/D58733
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
When we open a new window from a content process, we create a nested event
loop to wait for it to be initialized by the parent. The problem with this is
that the OpenWindow code which calls the window provider expects the window to
be in-process and uninitialized, so that it can load its own initial URI into
it, and correctly fulfil the spec-codified contract of window.open(). If
another caller initiates a load in the new window during the nested event
loop, those invariants are broken, and any manner of undefined behavior can
occur.
This patch adds a new flag to the BrowsingContext, marking it as uninitialized
until the end of the nested event loop, and blocking any attempts to load a
new URI into it in the meantime.
Differential Revision: https://phabricator.services.mozilla.com/D57667
--HG--
extra : moz-landing-system : lando
When we open a new window from a content process, we create a nested event
loop to wait for it to be initialized by the parent. The problem with this is
that the OpenWindow code which calls the window provider expects the window to
be in-process and uninitialized, so that it can load its own initial URI into
it, and correctly fulfil the spec-codified contract of window.open(). If
another caller initiates a load in the new window during the nested event
loop, those invariants are broken, and any manner of undefined behavior can
occur.
This patch adds a new flag to the BrowsingContext, marking it as uninitialized
until the end of the nested event loop, and blocking any attempts to load a
new URI into it in the meantime.
Differential Revision: https://phabricator.services.mozilla.com/D57667
--HG--
extra : moz-landing-system : lando
IsTypeSupported requires a docshell in order to determine if plugins are allowed. This adds a static version that lets the caller provide their own value for allowing plugins.
Differential Revision: https://phabricator.services.mozilla.com/D56132
--HG--
extra : moz-landing-system : lando
IsTypeSupported requires a docshell in order to determine if plugins are allowed. This adds a static version that lets the caller provide their own value for allowing plugins.
Differential Revision: https://phabricator.services.mozilla.com/D56132
--HG--
extra : moz-landing-system : lando
Before DocumentChannel, unknown protocol errors happened when we tried to create the channel, so didn't go through this path. With DocumentChannel we don't find out until we're in the parent process, so they come through as a failed request value, which encounters these filters.
Depends on D56841
Differential Revision: https://phabricator.services.mozilla.com/D57030
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
CheckMayLoadAndReport takes a window ID. This allows us to report
errors from it to the web console as needed. Most consumers know statically
whether they want reporting or not, so there's no reason to force the ones that
don't to provide window ids.
Differential Revision: https://phabricator.services.mozilla.com/D56388
--HG--
extra : moz-landing-system : lando
Fission puts subdocuments (potentially) in separate processes, so we can't
just EnumerateSubDocuments and poke the TimeoutManagers for each one.
Differential Revision: https://phabricator.services.mozilla.com/D56547
--HG--
extra : moz-landing-system : lando
Any number of outer windows may be attached to a BrowsingContext over its
lifetime. While the BrowsingContext is alive, it's easy to keep track of which
of these is active, and therefore which of its inner windows is active. After
it has been discarded, though, it discards its docShell reference, so all we
can tell about an inner window is whether it is active for its own outer
window, but not whether it should be considered active for its
BrowsingContext.
This patch updates the BrowsingContext detach logic to store a flag on the
current inner window recording that it was active when its BrowsingContext was
detached, and then later checks that flag to determine if it is the current
window for a detached BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D49032
--HG--
extra : moz-landing-system : lando
CheckMayLoadAndReport takes a window ID. This allows us to report
errors from it to the web console as needed. Most consumers know statically
whether they want reporting or not, so there's no reason to force the ones that
don't to provide window ids.
Differential Revision: https://phabricator.services.mozilla.com/D56388
--HG--
extra : moz-landing-system : lando
There are no callers of findChildWithName after it got replaced by
corresponding methods in BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D55977
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This reference is necessary when sending session storage data for
all browsing context to the parent process. Note that it entails
making SessionStorageManager a cycle collection participant, since
adding this reference creates a cycle.
Differential Revision: https://phabricator.services.mozilla.com/D55659
--HG--
extra : moz-landing-system : lando
With Fission enabled we do not necessarily have access to the
nsDocShell that holds the top-level browsing context, so the
BrowsingContext is a better place to store information that needs
to be accessible to nested browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D55276
--HG--
extra : moz-landing-system : lando
This reference is necessary when sending session storage data for
all browsing context to the parent process. Note that it entails
making SessionStorageManager a cycle collection participant, since
adding this reference creates a cycle.
Depends on D55276
Differential Revision: https://phabricator.services.mozilla.com/D55659
--HG--
extra : moz-landing-system : lando
With Fission enabled we do not necessarily have access to the
nsDocShell that holds the top-level browsing context, so the
BrowsingContext is a better place to store information that needs
to be accessible to nested browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D55276
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
Some of these were obvious typos. Others probably reflect once-correct components
that have been combined, split, or otherwise obsoleted; for these I've tried to
use the component associated with the bugs for recent changes to the affected files.
Differential Revision: https://phabricator.services.mozilla.com/D55756
--HG--
extra : moz-landing-system : lando
* Removed the STATUS_LINK constant.
* Removed the statusType parameter from nsIWebBrowserChrome::setStatus.
* Removed the setStatusWithContext method. No one uses the information from
statusContext.
* Removed the nsIWebBrowserChrome2 interface as setStatusWithContext was the
only method.
Differential Revision: https://phabricator.services.mozilla.com/D55195
--HG--
extra : moz-landing-system : lando
We normally get HttpChannelParent::OnStartRequest directly from nsHttpChannel::OnStartRequest, where we disable content conversion and ask the child to do it instead.
When we install a multipart converter, we defer calling HttpChannelParent::OnStartRequest until we've decoded parts, at which point content conversion is already applied to the stream.
This detects that case, and stops the child trying to do it a second time (which fails, and breaks the content).
Differential Revision: https://phabricator.services.mozilla.com/D55222
--HG--
extra : moz-landing-system : lando
Previously this error occurred synchronously during AsyncOpen, and we handled it there.
With DocumentChannel we don't find out until it's handled in the parent, so the error is returned to the docshell via a failed status on the request.
Differential Revision: https://phabricator.services.mozilla.com/D54248
--HG--
extra : moz-landing-system : lando
Previously this error occurred synchronously during AsyncOpen, and we handled it there.
With DocumentChannel we don't find out until it's handled in the parent, so the error is returned to the docshell via a failed status on the request.
Differential Revision: https://phabricator.services.mozilla.com/D54248
--HG--
extra : moz-landing-system : lando
Previously this error occurred synchronously during AsyncOpen, and we handled it there.
With DocumentChannel we don't find out until it's handled in the parent, so the error is returned to the docshell via a failed status on the request.
Differential Revision: https://phabricator.services.mozilla.com/D54248
--HG--
extra : moz-landing-system : lando
Instead of setting MOZ_QUIET to hide the DOMWINDOW and DOCSHELL log messages, you
now must set a regular logging module to enable them. They are automatically enabled
on tests that rely on these messages are leak checking.
That module is DocShellAndDOMWindowLeak:3
One disadvantage of this change is that you cannot set MOZ_QUIET to hide these
messages when running those tests (primarily browser-chrome).
Differential Revision: https://phabricator.services.mozilla.com/D52413
--HG--
extra : moz-landing-system : lando
The change to moz.build unveiled a couple unified build issues that I also had
to fix.
Depends on D55365
Differential Revision: https://phabricator.services.mozilla.com/D55366
--HG--
extra : moz-landing-system : lando
Bug 1534012 added a test for postMessage during load and that revealed that mLoading flag isn't always updated
soon enough, so add BrowsingContext::IsLoading which checks also possible local loading status.
Depends on D54754
Differential Revision: https://phabricator.services.mozilla.com/D54836
--HG--
extra : moz-landing-system : lando
The patch moves DeprioritizedLoadRunner handling from top level inner window to top level browsing context.
Differential Revision: https://phabricator.services.mozilla.com/D54754
--HG--
extra : moz-landing-system : lando
There's just no use for it, it was an unnecessary virtual interface, with a single concreate class and only ever used in C++.
Differential Revision: https://phabricator.services.mozilla.com/D55069
--HG--
extra : moz-landing-system : lando
Initially this was going to be a simple cleanup: Remove some useless namespaces
here and there and so on, remove `using` statements from the header and so on.
But unfortunately, DOMIntersectionObserver.h (which is included in Element.h,
unnecessarily) ended up exposing `Element` unnamespaced to a lot of code, so I
had to fix that.
Differential Revision: https://phabricator.services.mozilla.com/D55316
--HG--
extra : moz-landing-system : lando
This ensures that we wait for the desired URL in the browserLoaded call, rather
than resolving the first-loaded one.
This also renames the file to make it more indicative of what it actually tests.
Differential Revision: https://phabricator.services.mozilla.com/D55045
--HG--
extra : moz-landing-system : lando
This allows test toolkit/components/places/tests/browser/browser_multi_redirect_frecency.js and others to pass when fission is enabled.
The content process expects to know the chain of redirects encountered while opening a URI. The DocumentChannelParent gather that information and sends it to the new ContentChild which can then propagate the information to the new nsDocShell.
The data used to only be passed around during same-origin redirects when fission mode was enabled.
In order to allow for move semantics and preventing unnecessary copy of the DocumentChannelRedirect array, we make the nsIChildProcessChannelListener::onChannelReady property C++ only (noscript).
As we have only one concrete nsIChildProcessChannelListener class (ChildProcessListener) and that the unique OnChannelReady implementation is infallible; we really don't need for the method to return nsresult (so we declare it nostdcall). This helps simplify that call.
Differential Revision: https://phabricator.services.mozilla.com/D54909
--HG--
extra : moz-landing-system : lando