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 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
This is all super-hacky (see a lot of the XXXcjones comments).
Simplify it... We never create widgets with a bare native parent but no
nsIWidget parent. Pass nsIWidgets and deal with things correctly.
There were also things that were dealing with stuff that can't happen,
like top level popups, children of PuppetWidgets, or such.
Instead of overriding Create(), let's just teach nsBaseWidget about
non-native (headless/puppet) widgets.
Remove lots of old APIs for the native window stuff that are unused
and/or unimplemented.
Differential Revision: https://phabricator.services.mozilla.com/D224613
Much like we do with downloads (bug 1656925), these don't unload the
current document.
This prevents them from having mismatched flags, which asserts, see the
test-case.
Differential Revision: https://phabricator.services.mozilla.com/D224606
Previously, this was passed around using the nsHashPropertyBag base
class on HTTP channels. In bug 1907269, this base was added to
nsExtProtocolChannel to support reading this property for external
protocols.
This unfortunately ended up not working when a HTTP channel redirects to
an external protocol, as the hash property propagation logic in
nsHttpChannel happens after the check that the target channel is a HTTP
channel, so the property was lost when redirecting to an external
protocol.
Rather than refactoring HTTP redirect logic, this patch simplifies by
moving the property onto the LoadInfo where it will be trivially
preserved across redirects, and available in the places which need it.
Because the nsHashPropertyBag base is no longer required for
nsExtProtocolChannel, it is also removed.
Differential Revision: https://phabricator.services.mozilla.com/D220744
Previously this load would be allowed due to the "web-controlled" check
failing to reject the load. This patch instead bases it on the
docshell.newWindowTarget flag, which is set for the first load in a new
DocShell due to a call to window.open or target=_blank.
This required making the external protocol channel be a property bag so
that the flag can be set on the channel. In the future we may want to
switch this flag to being set in a more generic way which is less
specific to the channel.
Differential Revision: https://phabricator.services.mozilla.com/D217484
Previously this load would be allowed due to the "web-controlled" check
failing to reject the load. This patch instead bases it on the
docshell.newWindowTarget flag, which is set for the first load in a new
DocShell due to a call to window.open or target=_blank.
This required making the external protocol channel be a property bag so
that the flag can be set on the channel. In the future we may want to
switch this flag to being set in a more generic way which is less
specific to the channel.
Differential Revision: https://phabricator.services.mozilla.com/D217484
