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
Don't limit recursive checks to only happen for original src
loads. They're very likely to be loads of 'about:blank' and later
followed by the actual load. Make sure to check the following loads as
well.
Differential Revision: https://phabricator.services.mozilla.com/D222485
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
It would seem sometimes in Firefox 77 we regressed the ability to set the TRR
mode for a browsing context when opening a new tab.
I confirmed that this bug didn't happen in Fx 77 when setting the
`browser.tabs.documentchannel.parent-initiated` pref to `false`.
The nsIWebNavigation::LOAD_FLAGS_DISABLE_TRR is correctly passed into
CanonicalBrowsingContext, but it doesn't end up getting used.
This sets the appropriate DefaultLoadFlags for BrowsingContext
when the LOAD_FLAGS_DISABLE_TRR or LOAD_TRR_ONLY_MODE flags are present
in nsDocShellLoadState::LoadFlags()
Differential Revision: https://phabricator.services.mozilla.com/D220550
Your patch looks good to me. Not sure if there's a non-racy way of
testing the internal full-zoom value here...
But in general, assuming consistent zoom lacking other sources of
information seems like the right thing to do.
I agree that eventually we want to probably move the site-specific zoom
impl into Gecko (if only because Android is also going to want that, see
bug 1547181, where I added a comment).
Co-authored-by: Nika Layzell <nika@thelayzells.com>
Differential Revision: https://phabricator.services.mozilla.com/D220277
The console notification is only created when an error page would not
otherwise load, so allows us to detect the situation where the error
page is not going to be loaded.
Differential Revision: https://phabricator.services.mozilla.com/D218984
Currently, when a page enters BFCache, it updates the parent process
for the active BC; however, the page that is about to show will do the
same. These two operations are triggered in different processes with
different active id, they are racy and problematic.
This patch fixes the above issue by not updating the parent process
when a page enters BFCache.
This only applies to BFCacheInParent is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D215818
This patch switches the main logic from a boolean pref to an integer with different feature modes.
See nsIBounceTrackingProtection for the new modes supported. Dry-run mode has been merged into the mode
pref.
A new state is introduced MODE_ENABLED_STANDBY in which BTP still collects user activation signals, but
does not classify or purge bounce trackers. This new mode should be used when it's expected that the
feature may be toggled on/off after rollout. Collecting user activation even in the "disabled" state
ensures that when the feature gets re-enabled the user activation map is already warmed up and sites
important to the user are not classified + purged.
The BounceTrackingProtection singleton listens for changes on the mode pref and inits / tears down accordingly.
However it never shuts down fully. To fully disable the feature a restart is required.
Differential Revision: https://phabricator.services.mozilla.com/D217848
The console notification is only created when an error page would not
otherwise load, so allows us to detect the situation where the error
page is not going to be loaded.
Depends on D217495
Differential Revision: https://phabricator.services.mozilla.com/D218984
Previously these checks were largely diagnostic tools for finding bugs
in other code as it evolves. This unifies the checks a bit more and
makes them stronger for BrowsingContexts created over IPC, providing a
place for more coherency checks to be added in the future.
Differential Revision: https://phabricator.services.mozilla.com/D218860
