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
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
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
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
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
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
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
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
