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
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
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
* 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
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
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
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
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
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
The previous site URI is now only written on the parent and sent back to the child once all redirects have completed.
In a follow up we will also transfer this information when a process switch occur as it's currently broken.
Differential Revision: https://phabricator.services.mozilla.com/D53926
Rather that setting the property bag on both the child and parent from the docshell; we first set it on the parent instead, and once the redirect (or process switch) has completed we carry that bag across.
Differential Revision: https://phabricator.services.mozilla.com/D53924
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
This fixes the content policy type for document loads in these frames, where
the explicit mIsFrame flag was not set, due to DocShell creation taking a
different code path in remote frames than in in-process frames.
Differential Revision: https://phabricator.services.mozilla.com/D52093
Exposes a new nsIDocShell API, isForceReloading, to determine if
the loaded document was force-reloaded or not.
It relies on the underlying behaviour of nsDocShell::IsForceReloading(),
which again relies on nsDocShell::IsForceReloadType(mLoadType).
The getter is used in the remote agent to test that
Page.reload({ignoreCache: true}) works as intended.
Differential Revision: https://phabricator.services.mozilla.com/D51435
We can remove isOnlyToplevelInTabGroup entirely since we have
BrowsingContext/BrowsingContextGroup exposed through
chrome-webidl. Checking if a browsing context is the only top level
(auxilliary or otherwise) is only a matter of checking that there
isn't a parent, and that the size of the browsing context group is 1.
Differential Revision: https://phabricator.services.mozilla.com/D46590
