In bug 1579049, response code 403 and 501 were changed to map to `NS_ERROR_PROXY_FORBIDDEN` and `NS_ERROR_PROXY_NOT_IMPLEMENTED`. This caused a regression, since 403 and 501 were mapping to `NS_ERROR_PROXY_CONNECTION_REFUSED` before. This patch fixes the regression by adding `NS_ERROR_PROXY_FORBIDDEN` and `NS_ERROR_PROXY_NOT_IMPLEMENTED` to nsDocShell.
Differential Revision: https://phabricator.services.mozilla.com/D61682
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
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
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
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
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
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
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
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
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
