Not sure how to create a reduced test-case for this. This is not very
problematic in any case since the canvas bg will only last while the
presshell is not initialized.
Differential Revision: https://phabricator.services.mozilla.com/D255656
This reverts commit efd9a5ba48.
Revert "Bug 1968644 - Part 9: Add more tests for loads triggered by tracking scripts. r=valentin,anti-tracking-reviewers,emz"
This reverts commit 7d5c3e1c1c.
Revert "Bug 1968644 - Part 8: Populate the triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for WebSocket requests. r=valentin,necko-reviewers"
This reverts commit 53a783a51e.
Revert "Bug 1968644 - Part 7: Add tests. r=necko-reviewers,anti-tracking-reviewers,emz,valentin"
This reverts commit e52f034955.
Revert "Bug 1968644 - Part 6: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags during channel creation. r=necko-reviewers,kershaw"
This reverts commit f564c21b37.
Revert "Bug 1968644 - Part 5: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for CSS loads. r=emilio"
This reverts commit 8a8fd7bacc.
Revert "Bug 1968644 - Part 4: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for loads. r=smaug,necko-reviewers"
This reverts commit 7b3ba3b668.
Revert "Bug 1968644 - Part 3: Populate the triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for fetch requests. r=valentin,smaug"
This reverts commit 08f090244f.
Revert "Bug 1968644 - Part 2: Intorduce the ClassificationFlags to nsIClassifiedChannel.idl. r=dimi,necko-reviewers,valentin"
This reverts commit b8c01cd77c.
Revert "Bug 1968644 - Part 1: Introduce triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags to LoadInfo. r=necko-reviewers,kershaw"
This reverts commit a7619a72b4.
This inverts the relationship between nsDocShell::Reload and
nsDocShell::ReloadNavigable, making nsDocShell::Reload be exclusively
a UI operation and really only a thin wrapper around
nsDocShell::ReloadNavigable. Also change Location.reload to use
nsDocShell::ReloadNavigable.
Differential Revision: https://phabricator.services.mozilla.com/D253465
The changes from the previous patch to re-throttle OnStatusChange and
OnProgressChange appear to have not been enough. It appears that we are
also seeing a substantial amount of IPC overhead due to sending
OnStateChange notifications to the parent process for subresources, such
as images.
This re-adds some filtering (though it is still more relaxed than the
filtering was before bug 1963189) to OnStateChange notifications, so
that only notifications relevant to primary document loads will be sent
over IPC.
This particular filtering is done in the OnStateChange listener, as
listeners in the parent process may care about
STATE_IS_REDIRECTED_DOCUMENT, which cannot be filtered for at
registration time.
Differential Revision: https://phabricator.services.mozilla.com/D253411
A transient entry will be replaced if a new entry is added on top.
This patch achieves multiple goals
- nsISHEntry.persist is renamed to transient and defined more precisely.
- aPersist is removed as argument to several methods.
- Instead, we call SetTransient() directly on the entry.
- These methods mostly forwarded aPersist to nsSHistory::AddEntry, if they
called it. But that meant that passing false for aPersist didn't always
result in transient entries.
- We create the infrastructure for transient child entries to be replaced too.
- Previously, the persistence flag was ignored on child entries
- At the state of this patch, child entries shouldn't become transient. But
they will once we always replace the initial about:blank entry.
Differential Revision: https://phabricator.services.mozilla.com/D250233
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
A smallish re-factor aligning us more with spec allows us to use our new
reload path, which also aligns us more with spec. Also fixes issues
around event cancellability.
Differential Revision: https://phabricator.services.mozilla.com/D250902
A smallish re-factor aligning us more with spec allows us to use our new
reload path, which also aligns us more with spec. Also fixes issues
around event cancellability.
Differential Revision: https://phabricator.services.mozilla.com/D250902
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
A smallish re-factor aligning us more with spec allows us to use our new
reload path, which also aligns us more with spec. Also fixes issues
around event cancellability.
Differential Revision: https://phabricator.services.mozilla.com/D250902
In this patch, we populate the partitionedPrincipal when we commit
SessionHistory to the parent process. In addition, we remove the
serialization and deserialization of partitionedPrincipalToInherit in
sessionHistory.
Differential Revision: https://phabricator.services.mozilla.com/D250263
A smallish re-factor aligning us more with spec allows us to use our new
reload path, which also aligns us more with spec. Also fixes issues
around event cancellability.
Differential Revision: https://phabricator.services.mozilla.com/D250902
In this patch, we populate the partitionedPrincipal when we commit
SessionHistory to the parent process. In addition, we remove the
serialization and deserialization of partitionedPrincipalToInherit in
sessionHistory.
Differential Revision: https://phabricator.services.mozilla.com/D250263
Intercept was prevented by four things:
1) the return value of FirePushReplaceReloadNavigateEvent for
pushState was used inverted.
2) the event was created untrusted
3) the wrong flag was being checked to see if the event was in the
process of being dispatched.
4) wrong uri equality method was used.
Differential Revision: https://phabricator.services.mozilla.com/D248222
Download request navigate events are fired from
turn is called e.g from the activation behavior of a and area elements
in the case of a download attribute being present.
Also split nsContentUtils::TriggerLink into separate click and
mouse-over cases.
Differential Revision: https://phabricator.services.mozilla.com/D247903
According to the spec, canceling lazy loading should happen before
navigating to a fragment. If we cancel lazy loading in DoURILoad,
we won't cancel for same document navigation.
To my knowledge, this hasn't been an issue. But with sync-about-blank,
this would break wpt iframe-loading-lazy-nav-link-click-fragment.html.
Differential Revision: https://phabricator.services.mozilla.com/D234665
Frédéric Wang