In most cases NOTREACHED() is now a better option. Also performs
dead-code removal.
Bug: 40122554
Low-Coverage-Reason: OTHER Should-be-unreachable code
Change-Id: I3d9054619242c472feadab98d9de4024c74d4992
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6013928
Commit-Queue: Avi Drissman <avi@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Auto-Submit: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1385678}
Android content-URIs do not contain the names of subdirs like paths in
posix or windows do.
This CL is a nop to add the field to mojom and update any affected
clients. It is part of a series of CLs to get webkitRelativePath
working for android content-URIs.
Bug: 377716464
Change-Id: Idaa6de86d81a705c4d7758929b34ea5ef2101a83
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6000058
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Joel Hockey <joelhockey@chromium.org>
Reviewed-by: Hidehiko Abe <hidehiko@chromium.org>
Reviewed-by: Sam McNally <sammc@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1381493}
This CL does not change any behavior; it is a mechanical change that
introduces a new 2-state enum to replace a boolean, and renames the
associated methods/variables.
(This CL also includes the corresponding mojo version of the enum, and
EnumTraits specialization and tests.)
This CL *does* change a test (url_request_mojom_traits_unittest.cc) to
supply a non-default value for the relevant field, rather than the
field's default value (since this test is about round-tripping the
mojo struct).
Bug: b:348671111, 344608182
Change-Id: I89c8657235e60734513cfc840fe61d3c12b80a77
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5683463
Commit-Queue: Chris Fredrickson <cfredric@chromium.org>
Auto-Submit: Chris Fredrickson <cfredric@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Owners-Override: Nico Weber <thakis@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1325075}
To address breakage of named window reuse across a back navigation
when a proactive BrowsingInstance swap has happened, we offer the
option to use an explicit opener relation for same-window navigations
as an opt-out from proactive swaps. This applies to elements that
support rel=opener (a, area, and form). We also introduce "opener"
as a window feature (for window.open()).
Usage looks like the following:
Before:
<a href="next.html">next</a>
After:
<a href="next.html" rel="opener">next</a>
Before:
location.href = getNextPageUrl();
After:
window.open(getNextPageUrl(), '_self', 'opener');
Note that the opt-out only affects proactive swaps. It cannot be used
to bypass swaps that are required (e.g. for COOP).
Usage of conflicting rel types (rel="noopener opener") resolves in
favour of noopener.
WPTs still need to be added in a future CL.
Explainer: https://github.com/explainers-by-googlers/future-browsing-context-group-dependency-hint
Intent to Prototype: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/sI1zySADmNs
Bug: 333743493
Change-Id: Ie25acba119de231ed2b2532c2c1c2212e705264c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5560607
Reviewed-by: Brendon Tiszka <tiszka@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Stephen Nusko <nuskos@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Commit-Queue: Kevin McNee <mcnee@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1320669}
At present, the length of the initiator_base_url sent from the renderer
to the embedder is not checked. If that length exceeds url::kMaxURLChars
then Mojo will replace it with an empty GURL, causing the
CommonNavigationParams sent to have an empty base url value that
is not nullopt. This leads to a check failure in
NavigationRequest's constructor.
This CL checks the base url value in the renderer, and if it exceeds
the maximum length, does not include it in CommonNavigationParams.
If the browser receives a non-nullopt initiator_base_url with an
empty url, it's assumed something is wrong and the renderer is
terminated with BADMESSAGE.
Bug: 346908892
Change-Id: Ibea8740099af7269b5e46b25e06923c5edc33c74
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5641878
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Luc Nguyen <lucnguyen@google.com>
Commit-Queue: James Maclean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1318077}
VerifyInitiatorOrigin() is used to validate the initiator origin when
starting navigations via RenderFrameHostImpl's BeginNavigation() and
OpenURL(), as well as starting downloads via DownloadURL(). It currently
gives a free pass to all opaque initiator origins with an early return.
This CL improves that checking, such that we only skip initiator
origin validation for the two known cases that matter: error pages and
MHTML subframes. Other opaque origins are now validated properly,
including checking their precursor. This improves security of
sandboxed frames, ensuring they can't just start navigations with
random initiators. Error pages were already mentioned as the reason
for the original exception, and CQ tests revealed that another
exception is needed for MHTML subframes, which matches an exception
already granted to them in
RenderFrameHostImpl::CanCommitOriginAndUrl().
Error pages are already allowed to commit any URL at DidCommit time -
see how ValidateDidCommitParams() uses
RenderFrameHostImpl::ShouldBypassSecurityChecksForErrorPage(). So it
makes sense to allow navigations such as reloads of error pages to
also start with an mismatched initiator origin, which can happen
because the error's opaque origin has a precursor that's based on the
original (failed) URL, which may not match the error's process lock
(e.g., chrome-error://chromewebdata).
In addition, this change revealed a few tests that were inadvertently
injecting new frames on error pages (not realizing that a prior
navigation failed) and then navigating them. This included both
subframes [1][2] and in one case, a main frame [3] created on an error
page via window.open() (!). These tests will be separately fixed to
avoid unintended error pages (e.g., see https://crrev.com/c/5593650),
but we know from previous bugs that this is actually possible in
practice, e.g. if a frame is injected manually into an error page via
DevTools or automation (https://crbug.com/40246029). To handle those
cases, this CL also makes a change to allow frames injected on error
pages to inherit the is_error_document() status, such that we don't
end up with a new non-error initial blank frame (which is always
in the same process) in the error page process.
[1] ContentSubresourceFilterThrottleManagerTest.FailedNavigationToErrorPage_NoActivation
[2] OrbAndCorsExtensionBrowserTest.FromForegroundPage_NoSniffXml
[3] LoginDetectionBrowserTest.PopUpBasedOAuthLoginFlow
Change-Id: I759ece55a7f28607b8bfc8d311421cbc0bf1ea09
Bug: 40109437
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5590305
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1315048}
After the DeferSpeculativeRFH feature, the speculative RFH may not be
created when the navigation starts. The CL adds test utilities to
explicitly wait for the creation of the speculative RFH including:
* New functions added to the TestNavigationManager to wait for the
speculative RFH and acquire the created speculative RFH.
* A new utility class SpeculativeRenderFrameHostObserver to wait for the
speculative RFH without throttling the navigation.
All the failing tests have been modified to cater to the new feature.
The CL for the DeferSpeculativeRFH feature can be found at:
crrev.com/c/5400835
The design doc for the test fixes can be found at:
https://docs.google.com/document/d/14-hslQc3whJ3wa0rse3jdg1pzr5OZUM-5qDOuPAj-8o/edit?usp=sharing
Bug: 332435024
Change-Id: Ib1957784580624cd2546d9dd7d93a27178c879a7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5401150
Reviewed-by: Jan Keitel <jkeitel@google.com>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Jiacheng Guo <gjc@google.com>
Cr-Commit-Position: refs/heads/main@{#1313739}
For cross-process postMessage, the browser process verifies the source
origin in the message to make sure it can legitimately be used by the
renderer process that sent the postMessage. However, that verification
currently skips opaque source origins. This CL fixes that hole by
plumbing the full source origin, rather than its serialized version,
into RouteMessageEvent(). The verification of opaque source origins
then uses ChildProcessSecurityPolicy::HostsOrigin(), which already
supports opaque origins (verifying that their precursor matches the
process lock) and performs additional enforcements for sandboxed frame
processes. Tests are added to cover both legitimate postMessages
involving sandboxed frames, as well a simulated compromised renderer
that attempts to use an opaque source origin with an incorrect
precursor.
One tricky part of this change is that source origin serialization
(which determines event.origin) is now done in the browser process via
url::Origin::Serialize(), rather than in the renderer process via
blink::SecurityOrigin::ToString(). The two are mostly identical,
except for one unfortunate difference in how they handle file: origins:
url::Origin always serializes them as "file://", while
blink::SecurityOrigin serializes them to "null" or "file://"
depending on the `allow_file_access_from_file_urls` flag in
WebPreferences. This difference is accounted for manually, and
eventually the hope is that file: origins become proper opaque origins
that always serialize to "null" (see https://crbug.com/40554285 and
https://crbug.com/40467682).
Bug: 40109437, 325410297
Change-Id: Ia938b55a49b4729759923c9f409c21ffc29fb1c2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5571105
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1310878}
It is safer to use the value returned from `SwapImplForTesting()` for
`GetForwardingInterface()`; this ensures that if multiple test
interceptors are installed for the same receiver, an incoming method
will chain to all the interceptors. This also follows the best practices
in the updated comments for mojo::test::ScopedSwapImplForTesting.
Change-Id: Ia219ae7064e6afda7da32d84b8273543ab5de659
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5520160
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1297568}
Before, using this helper required specifying the exact receiver type
(e.g. `mojo::AssociatedReceiver<blink::mojom::LocalFrameHost>`) as the
template arg. This is a bit unwieldy to write and results in nesting
angle brackets.
After this, the template argument is simply the type of the Mojo C++
interface, like any other receiver type. Internally, the helper now uses
a base::OnceClosure to type erase the cleanup logic.
Finally, also add some documentation, as well as a postcondition CHECK()
to ensure that nested interceptions are properly cleaned up.
Change-Id: I680cf8d8774da7182e305ed854511538079ab15b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5520159
Reviewed-by: Ken Rockot <rockot@google.com>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/main@{#1297567}
The canonical bug format is TODO(crbug.com/<id>). TODOs of the
following forms will all be migrated to the new format:
- TODO(crbug.com/<old id>)
- TODO(https://crbug.com/<old id>)
- TODO(crbug/<old id>)
- TODO(crbug/monorail/<old id>)
- TODO(<old id>)
- TODO(issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/u/1/issues/<old id>)
- TODO(bugs.chromium.org/<old id>)
Bug id mapping is sourced from go/chrome-on-buganizer-prod-issues.
See go/crbug-todo-migration for details.
#crbug-todo-migration
Bug: b/321899722
Change-Id: Ibc66b8c440e4bcdef414e77fef4d9874d2ea9951
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5493800
Auto-Submit: Alison Gale <agale@chromium.org>
Commit-Queue: Alison Gale <agale@chromium.org>
Reviewed-by: Peter Boström <pbos@chromium.org>
Owners-Override: Alison Gale <agale@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1293330}
This feature was used to ensure that a newly added check is safe to
deploy and will not cause unexpected high volume of violations.
Investigating crash reports at AllowBindings() reveals there are
some, but they are either unrelated to the CHECK itself, or the
client submitting the crash report runs with upwards of 200 flags
disabling various features, including security protections.
At this point the original change can be considered safe. It has
been in the tree for close to half year, therefore it is time to
remove the feature flag guarding it.
Bug: 1442346
Change-Id: Id4609f0a9f03575eb5bf8f6f2ef9304006ac23c0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5146876
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1288251}
Some commit-time checks are not performed on the URL in certain
edge cases, depending on the origin passed to
url::Origin::Resolve(url, origin). This change ensures both the
URL and origin are always checked.
The AdditionalNavigationCommitChecks feature flag can be used
to disable these extra checks if problems are encountered.
Bug: 324934416, 1380576
Change-Id: I6241cfbaed709f0402925a86ff88223494a29638
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5132388
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1260537}
Windows asan found some undefined behavior in my attempt to handle an invalid enum value. I've replaced that code path and its test with a DCHECK.
I've made the function under test more easily testable by separating the ExecutionContext from the actual thing we need to know: what's the current runtime's policy for token issuance and redepmption?
Fixed: 1419873
Change-Id: I0f05e0d198ba855c549c3180aff9be748fb4113b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5121913
Reviewed-by: Nate Chapin <japhet@chromium.org>
Commit-Queue: Jonathan Feinberg <feinberg@google.com>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1238382}
There are two headers to declare features in content.
- the public one: `content/public/common/content_features.h`
- the private one: `content/common/features.h`.
Unfortunately, most are declared in the public one, despite being used
privately exclusively. This violate the `content/public/` rules. This
patches provides a fix.
Parts of this patch was made programmatically using this script:
https://paste.googleplex.com/6699322946093056, with the following
output: https://paste.googleplex.com/5591288895242240
This patch:
1. Update `docs/how_to_add_your_feature_flag.md` to incentive
developers to the non public versions.
2. Move ~70 features back into the private version.
3. Programmatically update the includes to include the correct
#include header(s).
4. For consistency and minimizing the amount of files modified,
the two headers to use the `features::` namespace.
AX-Relnotes: n/a.
Change-Id: Id9126a95dfbc533d4778b188b659b5acc9b3d9e3
Bug: None
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4836057
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1194718}
Fenced frames have checks to make sure that focus cannot be pulled
programmatically across a fenced frame boundary. However, because of how
user activation works, all of the gating happens on the renderer side.
This is problematic because this allows a compromised renderer to pull
focus across a fenced frame boundary as much as it wants, which can be
used to open a communication channel.
This CL adds checks on the browser side to make sure that any renderer
that pulls focus across a fenced frame boundary was allowed to do so.
This handles every focus case, including tab traversals, clicking to
focus, programmatic focus, and accessibility-based focusing. If the
browser determines focus was not allowed, the plan is to consider the
renderer compromised and kill it. Right now, until we know for sure that
there are no false positives with this check, we will instead call
DumpWithoutCrashing() to be able to monitor this.
Note that the focus check will bad message the renderer in tests, CQ,
and ToT builds.
This CL introduces a new transient state tracking mechanism that will
track if a RFHI passing focus had transient user activation. As focus is
moved from one RFHI to the next (through the
RenderFrameProxyHost::AdvanceFocus and RenderFrameHostImpl::TakeFocus
calls), the transient user activation status will be passed with the
focus change.
A new transient state tracking mechanism is added to
RenderWidgetHostImpl to track if focus was lost between calls to
RenderFrameHostImpl::DidFocusFrame(). This is done in order to detect if
focus was moved from a page to a UI element (such as the navbar). This
is needed because focus moving from a UI element back to the page could
be considered a bad focus otherwise.
The logic that consumes user activation when crossing a fenced frame
boundary is moved from the renderer to the browser as part of this
change, since focus verification needs to complete before user
activation can be consumed.
Examples:
MainFrame(FF1):
- If the main frame currently has focus and we click on FF1, the focus
checks will succeed simply because the click action gave the fenced
frame user activation.
- If instead we <tab> focus from MainFrame to FF1, the focus transfer
into FF1 will succeed specifically because <tab> gives MainFrame user
activation (which allows it to transfer focus). FF1 script will observe
the focus transfer into it, but user activation will not come with it.
- If we move focus from FF1 to another element in FF1, focus will be
allowed because the change in focus does not cross into a fenced frame
boundary.
- If a compromised renderer tries to move focus from MainFrame to FF1
without user gesture, since there is no user gesture on either frames,
and since focus is crossing a fenced frame boundary, the browser will
reject the focus change and badmessage the renderer. Note that this CL
will only badmessage the renderer in tests, CQ, and ToT builds. All
other builds will instead call DumpWithoutCrashing() so we can monitor
potential missed corner cases.
MainFrame(FF1(FF2),FF3) with a focusable element only in MainFrame and
FF3:
- If we <tab> focus through the focusable elements, we will first focus
on the element in MainFrame. Focus is allowed because it is not crossing
a fenced frame boundary into a fenced frame. The MainFrame will also get
transient user activation as a result of this action. We then wait for
MainFrame's transient user activation to expire before performing the
next step.
- The next <tab> gets more complicated. MainFrame will get transient
user activation, and then (1) activate FF1's transient state, (2)
deactivate MainFrame's transient state, and (3) pass focus into FF1.
This passing of focus into FF1 is allowed because the transient state
has been activated as a part of the user-gesture-initiated focus from
MainFrame => FF1. However, there are no focusable elements in FF1 so,
through RenderFrameProxyHost::AdvanceFocus(), FF1 will (1) activate
FF2's transient state, (2) deactivate FF1's transient state, and (3)
pass focus to FF2.
- Focus is allowed in FF2 due to the transient state, but FF2 still
needs to pass focus to the next frame. Through
RenderFrameHostImpl::TakeFocus(), FF2 will (1) activate FF1's transient
state, (2) deactivate FF2's transient state, and (3) pass focus back up
to FF1. FF1 will perform the same actions with MainFrame, which in turn
will perform the same actions with FF3 through
RenderFrameProxyHost::AdvanceFocus().
- FF3 has an element it can focus, so FF3 will focus that element, and
the focus check will pass because its transient state is activated.
MainFrame(FF1(FF2),FF3) with a focusable element only in FF3:
- If we press <tab> for the first time, MainFrame will get user
activation as we start the same traversal process as outlined in the
previous example. We will end up with the element in FF3 getting focus.
- If we press <tab> again, focus will leave the RenderWidgetHost and go
into the UI. RenderWidgetHostImpl::LostFocus() will be called and it
will set `has_lost_focus_` to true.
- Pressing <tab> one more time will start the traversal process again.
However, this time, no frames will have user activation. Instead,
MainFrame will see that `has_lost_focus_` is true, and will activate its
transient state tracking mechanism due to that. It will then go through
the same traversal process, where this time the transient state tracking
mechanism will be active due to the RWH losing focus rather than the
focus originator having user activation.
See design document: https://docs.google.com/document/d/1DH9l2mQJbPBJkSEkyVQPpswLafEwSPvKybMJRfgNuhA/edit?usp=sharing
Change-Id: I4c771ac56605f204ef3facb501115ff8ce01b428
Bug: 1458985
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4572517
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Peter Beverloo <peter@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Commit-Queue: Liam Brady <lbrady@google.com>
Reviewed-by: Dominic Farolino <dom@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1184289}
In a followup, the `NavigateToURLFromRenderer*()` family and
`BeginNavigateToURLFromRenderer()` helpers will explicitly check that a
navigation starts. This causes browser tests that use these helpers to
test blocked/cancelled renderer-initiated navigations to start
failing/hanging, since they never reach the `DidStartNavigation()`
stage.
Instead, update the various tests to use `EvalJs()`, `ExecJs()`, or
`ExecuteScriptAsync()` as appropriate and document the recommended
patterns.
One exception to this is the interaction sequence test helpers in
//chrome: while those test helpers ought to be an ideal candidate for
`BeginNavigateToURLFromRenderer()`, the interaction sequence tests have
a tendency to use a top-level RunLoop.
Unfortunately, this breaks most content test helpers that use a RunLoop
to wait for some event X before returning to the caller: nested
RunLoops, for safety reasons, do not allow nestable tasks by default,
and thus, those test helpers never hear the event they are waiting for.
The workaround is to use `ExecJs()` for this one case, since Mojo still
allows incoming replies to be dispatched inside nested RunLoops.
Bug: 1220337
Change-Id: I0e81ea69114655952e8e22128b900add4a2e26d2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4511225
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Dana Fried <dfried@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1141169}
WebUI uses the concept of bindings to enable renderer-side
access to APIs such as chrome.send() or Mojo. Historically,
we have used these bindings for performing security checks
as that was a way to distinguish whether a process is for
a WebUI (and therefore privileged) or not.
At this point in time we rely on site isolation to lock all
WebUI processes to their site, so this CL is adding checks
to ensure this is always the case. Once this has been
confirmed, we can remove the security checks based on
bindings and purely rely on ProcessLock checks and site
isolation.
Bug: 1442346
Change-Id: I8d49d10781dc72da58f37467909857185c43f1e6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4505311
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1140393}
Add permissions policy for Private State Tokens issuance operation.
Update existing unit/browser tests. Add new unit/browser tests. Add
external WPT tests.
Permission Policy behavior:
1. If there are no permission policy response from server. PST
issuance can be enabled in iframes for same and cross origins
using allow attribute. See
private-state-token-issue-allowed-by-permissions-policy-attribute.tentative.https.sub.html
2. Issuance can be disabled via the new permission policy, see
private-state-token-issue-disabled-by-permissions-policy.tentative.https.sub.html and relevant header file.
3. Permissions-Policy: private-state-token-issuance=* enables
issuance. Cross origin iframes need allow attribute. See
permissions-policy/private-state-token-issue-enabled-by-permissions-policy.tentative.https.sub.html and relevant header file.
Fixed: 1434086
Change-Id: I02c41b45fab9415c135e74eb51d9033c308e7622
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4436709
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Aykut Bulut <aykutb@google.com>
Code-Coverage: Findit <findit-for-me@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#1135556}
This change modifies fenced frame tests in //content to use the
`config` attribute instead of `src`. The purpose of this change is to
prepare for the removal of the `src` attribute from
HTMLFencedFrameElement, which will be a big, API-breaking change.
A follow up CL will handle the rest of the browser tests.
By using the `config` attribute instead of `src`, the tests will
continue to function after the CL that ultimately removes `src` lands,
and helps make the size of that change smaller and more manageable.
Skipping test flakiness validation. Removing the parameterization of
some browser test classes seems to be hitting this bug on the
linux-lacros-rel trybot: https://crbug.com/1344573
Bug: 1428960
Validate-Test-Flakiness: skip
Change-Id: Ie163550cb443638d141a7e811409139275394b44
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4381950
Reviewed-by: Nan Lin <linnan@chromium.org>
Commit-Queue: Liam Brady <lbrady@google.com>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Reviewed-by: Yao Xiao <yaoxia@chromium.org>
Reviewed-by: Garrett Tanzer <gtanzer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1125586}
This CL is a proper fix for https://crbug.com/1423092, so that
non-self-initiated navigations where the initiator is same-site to
the destination URL, and the initiator has obtained storage access,
can include cookies via Storage Access API.
This CL does the following:
* Changes the existing has_storage_access bool in
CommonNavigationParams such that it represents *just* whether the
initiator had storage access (via document.requestStorageAccess),
and moves the bool to BeginNavigationParams.
* Introduces a new load_with_storage_access bool in
CommitNavigationParams, which represents whether the target of the
navigation should load with storage access already granted (i.e.
no explicit call to document.requestStorageAccess is required).
The has_storage_access bool is used by the NavigationURLLoaderImpl to
attach cookies via Storage Access API, if needed; and to initialize
the load_with_storage_access bool correctly (after taking additional
constraints into account).
Note that for security reasons, the bool that comes from the renderer
are not trusted; cookies are never accessible unless the renderer's
bool is true *and* there's a matching permission grant in the
network service (which comes from the browser process).
Fixed: 1418136, 1423092
Change-Id: I63f2d56fe309efa4211c82d287ae93456e9969a6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4362106
Commit-Queue: Chris Fredrickson <cfredric@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Dominic Farolino <dom@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1123018}
1) Adds a window.open() windowFeatures flag called "fullscreen"
and corresponding parsing and mapping code.
2) Adds some plumbing to a navigation requests which indicates that
the initiator requested the document to fullscreen after the
new content is created.
3) Adds the code initiate and process fullscreen when the appropriate
flag is set and Window Management permission is granted on the
initiator.
Bug: 1142516
Change-Id: I14bf51dbe0e29c0d68c13e1bf1badc5ebff3f64c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4072455
Commit-Queue: Brad Triebwasser <btriebw@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1121400}
This is a reland of commit b7b098100d
which fixes test expectations for the content browser test
"NavigateUnfencedTopAndGoBack" when bfcache is disabled.
Original change's description:
> Fenced frames: Remove mode attribute [2/N]
>
> This CL deletes the FencedFrameMode enum and disables the `mode` attribute of HTMLFencedFrameElement. (It will be fully removed in a follow-up CL.) Instead, the mode information is stored in
> `FencedFrameConfig` and `FencedFrameProperties`. This also means that
> the mode can change across different embedder-initiated navigations.
>
> This involves one significant change to fenced frame information flow:
> Instead of the FencedFrameProperties being stored in the root
> FrameTreeNode in NavigationRequest::DidCommitNavigation, it is stored
> slightly earlier in RenderFrameHostImpl::DidCommitNewDocument. This is
> so that the mode has already been set when ResetPermissionsPolicy() is
> called. This is purely a refactor.
>
> Removing the fenced frame mode attribute has one effect on WP-visible
> behavior: now there is no such thing as opaque ads mode using a
> non-opaque url. Therefore this CL also changes all tests that previously
> used opaque ads mode with a non-opaque url, to use a urn/config instead.
>
> Bug: 1347953
> Change-Id: I88ab14184dcc5eb10a115ed070aad6a3e83cfe8c
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4184456
> Reviewed-by: Jeremy Roman <jbroman@chromium.org>
> Commit-Queue: Garrett Tanzer <gtanzer@chromium.org>
> Reviewed-by: Alex Turner <alexmt@chromium.org>
> Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
> Reviewed-by: Dominic Farolino <dom@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1118694}
Bug: 1347953
Change-Id: I149833dfbae6d1d6ee6a65998e3678b48b24d768
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4353654
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Alex Turner <alexmt@chromium.org>
Commit-Queue: Garrett Tanzer <gtanzer@chromium.org>
Reviewed-by: Dominic Farolino <dom@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1119643}
This reverts commit b7b098100d.
Reason for revert: Suspected culprit for test failure: https://ci.chromium.org/p/chromium/builders/ci/linux-bfcache-rel/44833
Original change's description:
> Fenced frames: Remove mode attribute [2/N]
>
> This CL deletes the FencedFrameMode enum and disables the `mode` attribute of HTMLFencedFrameElement. (It will be fully removed in a follow-up CL.) Instead, the mode information is stored in
> `FencedFrameConfig` and `FencedFrameProperties`. This also means that
> the mode can change across different embedder-initiated navigations.
>
> This involves one significant change to fenced frame information flow:
> Instead of the FencedFrameProperties being stored in the root
> FrameTreeNode in NavigationRequest::DidCommitNavigation, it is stored
> slightly earlier in RenderFrameHostImpl::DidCommitNewDocument. This is
> so that the mode has already been set when ResetPermissionsPolicy() is
> called. This is purely a refactor.
>
> Removing the fenced frame mode attribute has one effect on WP-visible
> behavior: now there is no such thing as opaque ads mode using a
> non-opaque url. Therefore this CL also changes all tests that previously
> used opaque ads mode with a non-opaque url, to use a urn/config instead.
>
> Bug: 1347953
> Change-Id: I88ab14184dcc5eb10a115ed070aad6a3e83cfe8c
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4184456
> Reviewed-by: Jeremy Roman <jbroman@chromium.org>
> Commit-Queue: Garrett Tanzer <gtanzer@chromium.org>
> Reviewed-by: Alex Turner <alexmt@chromium.org>
> Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
> Reviewed-by: Dominic Farolino <dom@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1118694}
Bug: 1347953
Change-Id: Ieabaa39304f86738360a6b48341b4f09af292a3e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4347646
Commit-Queue: Dmitry Titov <dimich@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Dmitry Titov <dimich@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1118798}
This CL deletes the FencedFrameMode enum and disables the `mode` attribute of HTMLFencedFrameElement. (It will be fully removed in a follow-up CL.) Instead, the mode information is stored in
`FencedFrameConfig` and `FencedFrameProperties`. This also means that
the mode can change across different embedder-initiated navigations.
This involves one significant change to fenced frame information flow:
Instead of the FencedFrameProperties being stored in the root
FrameTreeNode in NavigationRequest::DidCommitNavigation, it is stored
slightly earlier in RenderFrameHostImpl::DidCommitNewDocument. This is
so that the mode has already been set when ResetPermissionsPolicy() is
called. This is purely a refactor.
Removing the fenced frame mode attribute has one effect on WP-visible
behavior: now there is no such thing as opaque ads mode using a
non-opaque url. Therefore this CL also changes all tests that previously
used opaque ads mode with a non-opaque url, to use a urn/config instead.
Bug: 1347953
Change-Id: I88ab14184dcc5eb10a115ed070aad6a3e83cfe8c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4184456
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Commit-Queue: Garrett Tanzer <gtanzer@chromium.org>
Reviewed-by: Alex Turner <alexmt@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Dominic Farolino <dom@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1118694}
Moves the existing Private Aggregation features and associated params to
blink. Also adjusts the FLEDGE extensions feature to be an associated
base::FeatureParam instead of a runtime-enabled feature; this aligns
with the other params and avoids unnecessary integration with the Origin
Trial framework.
Bug: 1422776
Change-Id: If6654bab66348cacb94825909dce4a24fa97959d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4321087
Reviewed-by: Qingxin Wu <qingxinwu@google.com>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Alex Turner <alexmt@chromium.org>
Reviewed-by: Dominic Farolino <dom@chromium.org>
Reviewed-by: Nan Lin <linnan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1118385}
We add the web-exposed method
`blink::FencedframeConfig::setSharedStorageContext()` so that a fenced
frame's embedder can write contextual information, as a string, to the
config prior to the fenced frame's navigation to the config.
Any contextual string, if set before navigation, is sent to the
browser process during navigation and will be housed in the browser's
`content::FencedFrameProperties`, which are attached to the fenced
frame root's `FrameTreeNode`.
Note that the shared storage context will not be propagated back to
the renderer during copying/redaction of the original config.
As we implement in follow-up work (https://crrev.com/c/4295926), the
context will only be sent to the renderer during creation of an
eligible shared storage worklet from inside the fenced frame, and will be only available inside the worklet's renderer process.
Full testing will be in the follow-up (https://crrev.com/c/4295926).
Bug: 1218540
Change-Id: I8b477d5a9acbb7ecef4af3f07a1b8031b2bbf32a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4300409
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Garrett Tanzer <gtanzer@chromium.org>
Commit-Queue: Cammie Smith Barnes <cammie@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1112549}
This reverts commit c8d82e5268.
Reason for revert: Unblocking revert at https://crrev.com/c/4295184
Original change's description:
> Reland "Consolidate iframe & object resource timing code paths"
>
> This is a reland of commit 5dcb6f7b01
>
> (Reland change: initializing
> WebNavigationTimings::parent_resource_timing_access, caught by MSAN)
> Original change's description:
> > Consolidate iframe & object resource timing code paths
> >
> > So far some of the logic in resource timing for subframe navigations
> > iframe/object/embed) was duplicated, e.g. both in blink and in content.
> >
> > This has led to race conditions, inconsistencies and sometimes
> > XSS leaks.
> >
> > This patch attempts to improve the situation by consolidating the code
> > paths:
> >
> > - NavigationRequest receives is_container_initiated, which ensures only
> > container-initiated navigations are reported to the parent. This
> > is a clarification of something that was ambiguous in the spec
> > previously (https://github.com/whatwg/html/issues/8846).
> > It later uses ParentResourceTimingAccess to decide if a navigation
> > should report to its parent with/without response details
> > (status code and mime-type), or not report at all (TAO-fail, not
> > an iframe, not container-initiated).
> >
> > - Both object fallbacks and cancelled navigations (204/205) report
> > to the parent via RenderFrameImpl, and blink converts that to a
> > ResourceTimingInfo object. This allows us to remove the duplicated
> > resource timing creation code in //content.
> >
> > - We report fallback resource timing also for plugin error events and
> > not only for load events.
> >
> > Bug: 1399862
> > Bug: 1410705
> > Change-Id: Id37d23cd02eee9e38f812e6f3da99caedafdee3d
> > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4214695
> > Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
> > Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> > Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
> > Commit-Queue: Noam Rosenthal <nrosenthal@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#1110433}
>
> Bug: 1399862
> Bug: 1410705
> Change-Id: Ica01bcc861ffd60909e9adad79ef2f71ab23f98e
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4296794
> Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
> Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
> Commit-Queue: Noam Rosenthal <nrosenthal@chromium.org>
> Reviewed-by: Yoav Weiss <yoavweiss@chromium.org>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1110858}
Bug: 1399862
Bug: 1410705
Change-Id: I35e3a03d38be4d2cc42d18ee0ed0296b978da090
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4299069
Auto-Submit: Sergey Poromov <poromov@chromium.org>
Reviewed-by: Sergey Poromov <poromov@chromium.org>
Owners-Override: Sergey Poromov <poromov@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Sergey Poromov <poromov@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1111499}
