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
This commit is a prerequisite for part 5 of this patch set.
This flag is set in the docshell, based on `user gesture activation`.
This is not necessarily sufficient,
as the text fragments spec bases the value of
this flag also on User Involvement, which is not
implemented in Gecko yet.
The flag is then plumbed through the parent process
(`DocumentLoadListener::CreateDocumentLoadInfo()`)
to the document, where it can be consumed.
This includes client-side redirects as described in [0].
There is no changed behavior in this commit.
[0] https://wicg.github.io/scroll-to-text-fragment/#restricting-the-text-fragment
Differential Revision: https://phabricator.services.mozilla.com/D212817
This commit is a prerequisite for part 5 of this patch set.
The idea is to keep the information whether the last
load done by the doc shell was a same-document navigation.
The value is reset for every navigation, therefore it
should always be correct.
There is no changed behavior in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D212818
This commit is a prerequisite for part 5 of this patch set.
This flag is set in the docshell, based on `user gesture activation`.
This is not necessarily sufficient,
as the text fragments spec bases the value of
this flag also on User Involvement, which is not
implemented in Gecko yet.
The flag is then plumbed through the parent process
(`DocumentLoadListener::CreateDocumentLoadInfo()`)
to the document, where it can be consumed.
This includes client-side redirects as described in [0].
There is no changed behavior in this commit.
[0] https://wicg.github.io/scroll-to-text-fragment/#restricting-the-text-fragment
Differential Revision: https://phabricator.services.mozilla.com/D212817
This patch makes some adjustments to follow the spec more strictly by
separating highlighting a text fragment (ie. adding the ranges to a `eTargetText` Selection)
from scrolling to it.
Scrolling to the text fragment now follows the steps given in [0] more closely,
in particular now the closest common ancestor of the target range is being used
as `:target` element.
This change also sets the focus to the start of the first text fragment, as indicated by the spec.
This resets the normal selection on the page.
The wpt test in /css/css-pseudo/target-text-005.html is based on the idea of having a same-doc
text fragment navigation with a selection.
This test fails with this patch applied, because the selection is reset.
It is currently unclear what behavior is correct here, thus the test is kept for now.
[0]: https://wicg.github.io/scroll-to-text-fragment/#invoking-text-directives
Differential Revision: https://phabricator.services.mozilla.com/D211025
This patch makes some adjustments to follow the spec more strictly by
separating highlighting a text fragment (ie. adding the ranges to a `eTargetText` Selection)
from scrolling to it.
Scrolling to the text fragment now follows the steps given in [0] more closely,
in particular now the closest common ancestor of the target range is being used
as `:target` element.
This change also sets the focus to the start of the first text fragment, as indicated by the spec.
This resets the normal selection on the page.
The wpt test in /css/css-pseudo/target-text-005.html is based on the idea of having a same-doc
text fragment navigation with a selection.
This test fails with this patch applied, because the selection is reset.
It is currently unclear what behavior is correct here, thus the test is kept for now.
[0]: https://wicg.github.io/scroll-to-text-fragment/#invoking-text-directives
Differential Revision: https://phabricator.services.mozilla.com/D211025
This changes where the IsUpgradeDowngradeEndlessLoop check triggers.
Before this patch, it triggered during the redirect caused by the https
upgrade. With this patch, it triggers during the downgrade for http
redirects. META and JS redirect are still detected during upgrade.
This should be fixed as a follow up (See Bug 1896691).
Downgrade in this context means same url, except with the scheme http
instead of https.
Different query parameters normally lead to different responses by web servers.
Don't consider the '#ref' part of the uri, because it doesn't get send to
the server and therefore can't change the server response.
We can't use the redirect chain anymore, because the query parameters
are trimmed since Bug 1715785.
This also removes the config option dom.security.https_only_check_path_upgrade_downgrade_endless_loop,
because it adds unnecessary complexity. Removing it for this patch is
easier.
https-only, https-first and httpssvc_https_upgrade tests had to be
modified, because they depended on the incorrect handling of query
strings in loop detection.
Differential Revision: https://phabricator.services.mozilla.com/D193672
This changes where the IsUpgradeDowngradeEndlessLoop check triggers.
Before this patch, it triggered during the redirect caused by the https
upgrade. With this patch, it triggers during the downgrade for http
redirects. META and JS redirect are still detected during upgrade.
This should be fixed as a follow up (See Bug 1896691).
Downgrade in this context means same url, except with the scheme http
instead of https.
Different query parameters normally lead to different responses by web servers.
Don't consider the '#ref' part of the uri, because it doesn't get send to
the server and therefore can't change the server response.
We can't use the redirect chain anymore, because the query parameters
are trimmed since Bug 1715785.
This also removes the config option dom.security.https_only_check_path_upgrade_downgrade_endless_loop,
because it adds unnecessary complexity. Removing it for this patch is
easier.
https-only, https-first and httpssvc_https_upgrade tests had to be
modified, because they depended on the incorrect handling of query
strings in loop detection.
Differential Revision: https://phabricator.services.mozilla.com/D193672
Thunderbird architecture does not currently allow for redirecting channels to
child processes, so new schemes need to be isolated to the parent process.
`x-moz-ews` was selected to clearly designate that the scheme is private and
restricted to Mozilla/MZLA code. It doesn't follow the RFC 7595 recommendation
to use a registered domain as a namespace, but this was felt to be unwieldy.
Differential Revision: https://phabricator.services.mozilla.com/D212439
`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
In theory, changing the return type from `nsIFrame*` to `ScrollContainerFrame*`
exposes `ScrollContainerFrame` to the callers who might not needed, but almost
all of the callers in cpp files are already exposed to `nsIScrollableFrame`, as
demonstrated in this patch via replacing the #include from
"nsIScrollableFrame.h" to "ScrollContainerFrame.h", so this is OK.
Some callers can be simplified since we no longer need `do_QueryFrame` to
`nsIScrollableFrame`.
Differential Revision: https://phabricator.services.mozilla.com/D211488
`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
In theory, changing the return type from `nsIFrame*` to `ScrollContainerFrame*`
exposes `ScrollContainerFrame` to the callers who might not needed, but almost
all of the callers in cpp files are already exposed to `nsIScrollableFrame`, as
demonstrated in this patch via replacing the #include from
"nsIScrollableFrame.h" to "ScrollContainerFrame.h", so this is OK.
Some callers can be simplified since we no longer need `do_QueryFrame` to
`nsIScrollableFrame`.
Differential Revision: https://phabricator.services.mozilla.com/D211488
