"no longer current window global" is the secondmost common NS_WARNING (at least on MacOS)
and "BrowsingContext is null or discarded" is the thirdmost, so change them to MOZ_LOG.
Also change the third one, for consistency.
Differential Revision: https://phabricator.services.mozilla.com/D263974
This is a very inelegant solution, which involves re-introducing the
hacky nsBrowserStatusFilter type as an intermediate listener between the
nsDocShell and the BCWebProgress.
A more elegant solution would be directly integrated into nsDocLoader,
which already holds all of the relevant state which is used to populate
status/progress change events on demand. However, this would be a more
substantial change, and this approach allows us to fix the performance
regression more quickly while also roughly keeping the old behaviour.
We could potentially fix this in a more elegant way as part of also
tracking progress for loads in out-of-progress iframes.
Differential Revision: https://phabricator.services.mozilla.com/D252586
Prior to this change, all web progress events fired by nsDocLoader
were bubbled to the toplevel in-process nsDocShell instance, then
captured by web progress listener. This listener would filter the
notifications (using nsBrowserStatusFilter), then send them either
directly to the BrowsingContextWebProgress, or via. PBrowser to the
BrowsingContextWebProgress.
Unfortunately, these events are modified as they are bubbled (e.g.
changing the progress flags to remove STATE_IS_NETWORK), which combined
with the filtering from nsBrowserStatusFilter led to some strange
behaviour in the notifications.
This change skips the in-content bubbling by directly propagating events
from the nsDocShell they were fired on to the corresponding
BrowsingContextWebProgress, and then performing the bubbling within the
parent process.
The one major exception to this is OnProgressChange, which relies on
nsDocLoader's handling on aCurTotalProgress and aMaxTotalProgress.
Because of that, these listeners continue to capture progress
notifications exclusively on the toplevel BrowsingContext, and do not
handle out-of-process iframes.
Differential Revision: https://phabricator.services.mozilla.com/D249651
Prior to this change, all web progress events fired by nsDocLoader
were bubbled to the toplevel in-process nsDocShell instance, then
captured by web progress listener. This listener would filter the
notifications (using nsBrowserStatusFilter), then send them either
directly to the BrowsingContextWebProgress, or via. PBrowser to the
BrowsingContextWebProgress.
Unfortunately, these events are modified as they are bubbled (e.g.
changing the progress flags to remove STATE_IS_NETWORK), which combined
with the filtering from nsBrowserStatusFilter led to some strange
behaviour in the notifications.
This change skips the in-content bubbling by directly propagating events
from the nsDocShell they were fired on to the corresponding
BrowsingContextWebProgress, and then performing the bubbling within the
parent process.
The one major exception to this is OnProgressChange, which relies on
nsDocLoader's handling on aCurTotalProgress and aMaxTotalProgress.
Because of that, these listeners continue to capture progress
notifications exclusively on the toplevel BrowsingContext, and do not
handle out-of-process iframes.
Differential Revision: https://phabricator.services.mozilla.com/D249651
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
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
This allows loads to be tracked as they are ongoing on a per-context basis in
the parent process, and for events to be generated for each subframe as it is
destroyed.
This patch also stops sending the `IsLoadingDocument` flag on the request to
the main process and removes RemoteWebProgress, as they are no longer necessary
due to being tracked directly.
Finally this patch also adds some logging to BrowsingContextWebProgress
to make it easier to diagnose this type of issue in the future.
Differential Revision: https://phabricator.services.mozilla.com/D115706
This allows loads to be tracked as they are ongoing on a per-context basis in
the parent process, and for events to be generated for each subframe as it is
destroyed.
This patch also stops sending the `IsLoadingDocument` flag on the request to
the main process and removes RemoteWebProgress, as they are no longer necessary
due to being tracked directly.
Finally this patch also adds some logging to BrowsingContextWebProgress
to make it easier to diagnose this type of issue in the future.
Differential Revision: https://phabricator.services.mozilla.com/D115706
This allows loads to be tracked as they are ongoing on a per-context basis in
the parent process, and for events to be generated for each subframe as it is
destroyed.
This patch also stops sending the `IsLoadingDocument` flag on the request to
the main process and removes RemoteWebProgress, as they are no longer necessary
due to being tracked directly.
Finally this patch also adds some logging to BrowsingContextWebProgress
to make it easier to diagnose this type of issue in the future.
Differential Revision: https://phabricator.services.mozilla.com/D115706
I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
Manuel Bucher