Modify the frame recursion check to only happen when a load is triggered
from a src or data attribute (depending on if it's an iframe, embed or
an object element). This prevents recursion checks from blocking
ordinary navigations and navigations with a target.
Differential Revision: https://phabricator.services.mozilla.com/D229503
This applies for refreshes resulting from either a `<meta>` refresh or
the Refresh header. Referrer Policy is honored.
Because exposing the referrer in a new place could have privacy
implications, this behavior is gated behind a disabled pref until
anti-tracking has been considered in bug 1928294.
Some WPTs that D227450 touches are cleaned up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D227450
When ReferrerInfo is exposed later in the patch set, using the document
referrer info instead of mReferrerInfo will matter, but for now,
behavior should be unchanged.
Optional argument aSendReferrer for the ReferrerInfo constructor is
added. Because the existing behavior of InitWithDocument setting
mSendReferrer to true is acceptable in all other cases, the
aSendReferrer argument is not passed to InitWithDocument and
nsIReferrerInfo.idl is unchanged.
Unused method ReferrerInfo::CloneWithNewSendReferrer is removed.
Differential Revision: https://phabricator.services.mozilla.com/D227449
This applies for refreshes resulting from either a `<meta>` refresh or
the Refresh header. Referrer Policy is honored.
Because exposing the referrer in a new place could have privacy
implications, this behavior is gated behind a disabled pref until
anti-tracking has been considered in bug 1928294.
Some WPTs that D227450 touches are cleaned up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D227450
When ReferrerInfo is exposed later in the patch set, using the document
referrer info instead of mReferrerInfo will matter, but for now,
behavior should be unchanged.
Optional argument aSendReferrer for the ReferrerInfo constructor is
added. Because the existing behavior of InitWithDocument setting
mSendReferrer to true is acceptable in all other cases, the
aSendReferrer argument is not passed to InitWithDocument and
nsIReferrerInfo.idl is unchanged.
Unused method ReferrerInfo::CloneWithNewSendReferrer is removed.
Differential Revision: https://phabricator.services.mozilla.com/D227449
MOZ_RUNINIT => initialized at runtime
MOZ_CONSTINIT => initialized at compile time
MOZ_GLOBINIT => initialized either at runtime or compile time, depending on template parameter, macro parameter etc
This annotation is only understood by our clang-tidy plugin. It has no
effect on regular compilation.
Differential Revision: https://phabricator.services.mozilla.com/D223341
PreserveLayers is propagated to child frames, and it'd be nice if it
could be used just the same way it's used for the top level tab, to
avoid discarding the resources.
For the top level, if you call preserveLayers() you also need to have
renderLayers = true.
It'd be better long-term, perhaps, to have renderLayers and
preserveLayers in the parent BC. Happy to work on that refactoring if
you agree.
Testing wise, I don't think this is easily testable...
Differential Revision: https://phabricator.services.mozilla.com/D227000
This behavior was already agreed upon in
<https://github.com/whatwg/html/issues/7386>, but bug 1544428 was an
implementation edge case needing to be fixed.
An exception is when the fragment contains a directive, in which case a
difference in `hasRef` is sufficient, to retain existing behavior WRT
directives.
Although bug 1544428 is about popstate, hashchange was erroneously being
dispatched, as well, which this patch fixes.
Some tests that depended on the old behavior are updated.
Differential Revision: https://phabricator.services.mozilla.com/D225567
To implement BFCache in Gecko, we complete loads in new
BrowsingContextGroups when it would be invisible to the site. This
allows us to suspend the previous document and its entire
BrowsingContextGroup and restore it when navigating back through
history.
Unfortunately the current logic does not catch one web-visible case,
which is when a document is put into the BFCache, and then the next page
opens a named pop-up window. After navigating back to the previous page,
we switch back to the previous BrowsingContextGroup, and opening the
same named window will create a distinct pop-up.
This patch proposes avoiding this by not restoring a session history
entry from the BFCache when the navigating BrowsingContext has auxiliary
BrowsingContexts. This is done lazily, so if the pop-up is closed before
the back navigation (e.g. due to it being used for an oauth flow), it
will not invalidate the BFCache entry.
Differential Revision: https://phabricator.services.mozilla.com/D226184
