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}
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: Ieeb461e2d489e86fd50b87a2a0721a2be34520c3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5467317
Owners-Override: Alison Gale <agale@chromium.org>
Commit-Queue: Darryl James <dljames@chromium.org>
Commit-Queue: Alison Gale <agale@chromium.org>
Reviewed-by: Darryl James <dljames@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1290198}
The changes of this CL are made using the following script.
```
target_directory="content/browser"
replace_string_in_files() {
old_string="$1"
new_string="$2"
find "$target_directory" -type f \( -name "*.cc" -o -name "*.h" \) \
-exec sed -i '' "s/$old_string/$new_string/g" {} +
}
delete_include() {
find "$target_directory" \( -name "*.h" -o -name "*.cc" \) -print0 | while IFS= read -r -d '' file; do
grep -v '#include "base/strings/string_piece.h"' "$file" > "$file.tmp" && mv "$file.tmp" "$file"
done
}
add_include() {
find "$target_directory" \( -name "*.h" -o -name "*.cc" \) -print0 | while IFS= read -r -d '' file; do
local include_added=false
local tempfile=$(mktemp)
if grep -qE 'std::(string|u16string)_view' "$file"; then
while IFS= read -r line; do
echo "$line" >> "$tempfile"
if [[ $line =~ ^\s*#include ]]; then
if ! $include_added; then
echo "#include <string_view>" >> "$tempfile"
include_added=true
fi
fi
done < "$file"
mv "$tempfile" "$file"
if $include_added; then
echo "Added #include <string_view> after the first include line in $file"
else
echo "No include line found in $file"
fi
else
echo "std::string_view not found in $file"
fi
done
}
replace_string_in_files "base::StringPiece16" "std::u16string_view"
replace_string_in_files "base::StringPiece" "std::string_view"
delete_include
add_include
```
Replaced base::StringPiece16 with std::u16string_view
Replaced base::StringPiece with std::string_view
Removed header "base/strings/string_piece.h"
Added header "<string_view>" where applicable
Bug: 40506050
Change-Id: I2bc22c79dd9a0c839745afe065123f7a53c4a5ca
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5401117
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1281746}
This patch implements the capability control for the preview mode.
We prepare a variant policy set for the preview mode so that we can
adjust the rule for a visible page.
Also, we pass a different cancel closure as we don't need to cancel
a prerendering, but just need to navigate to an error page that shows
an explanation why the page cannot be shown in the preview mode.
The error page handling, and disabling the control on tab promotions
are not implemented yet in this CL.
Bug: b/299240273
Change-Id: I705de780a83fe975b85c0ab567565342b7467da2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4941187
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Ken Okada <kenoss@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Lingqi Chi <lingqi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1212566}
activation
Prerender has to preform two-stage Mojo capability control to ensure
the status on the browser process and renderer processes are on sync.
For the second stage, prerender allows interfaces that can make sync
IPCs whose policies should be kCancel/kGrant to make IPCs.
However, some interfaces are treated in a different way: We defer the
binding requests on the renderer side, and resume them upon renderer
activation, so we can mark them kDefer. For these interfaces, they
should be treated as kGrant interfaces during the second stage.
So this CL fixes this issue which causes renderer hangs.
It is unfortunate that we have to add some hardcode rules for these
interfaces. This CL Left some TODOs that requires
I533dd0f0438d493ad8a7a74479526827bf93e1d9 to land first.
Bug: 1385623
Change-Id: I180c6f8b0cc37c4157346cc5a556cc07f8c2b1f5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4082358
Commit-Queue: Lingqi Chi <lingqi@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1083506}
The changes were generated by running
tools/clang/rewrite_raw_ref_fields/rewrite-multiple-platforms.sh with
tool-arg=--enable_raw_ref_rewrite
`raw_ref` is a smart pointer for a pointer which can not be null, and
which provides Use-after-Free protection in the same ways as raw_ptr.
This class acts like a combination of std::reference_wrapper and
raw_ptr.
See raw_ptr and //base/memory/raw_ptr.md for more details on the
Use-after-Free protection.
Bug: 1357022
Change-Id: I14c1f8d4d890715fb9b9f0526ace78ecc625c08a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3999748
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Ali Hijazi <ahijazi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1068278}
Mojo message calls
This CL adds a DCHECK into MojoBinderPolicyApplier::GrantAll() to ensure
this method is called within Mojo message call stacks.
We should guarantee it because MojoBinderPolicyApplier::GrantAll()
invokes BrowserInterfaceBrokerImpl::BindInterface(), and the
BindInterface() method may call mojo::ReportBadMessage(), which should
be called within a stack frame of a Mojo message dispatch.
(Now mojom::LocalFrameHost::DidActivateForPrerendering() invokes
MojoBinderPolicyApplier::GrantAll(). See the issue description for more
information.)
Bug: 1217977
Change-Id: Ib63811a753243756b778b1a1f02f5aa616dedeba
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2952745
Commit-Queue: Lingqi Chi <lingqi@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#892439}
prerenderingchange"
This relands commit Ib3da39f9cae6b1a46d08a64d8f41b5f5b50460c0.
The added test failed on the LaCrOS builds because of the use of the
Gamepad API. This CL relands the test except for the LaCrOS builds.
Also this adds a new test using the NotificationService interface to
keep the test coverage on the LaCrOS builds.
Original change's description:
> For prerendering, MojoBinderPolicyMapApplier wants to loosen the
> kCancel policy slightly before the activation is complete.
>
> The activation of a prerendered page follows the steps below.
> 1. The activation navigation to the prerendered page is committed.
> 2. PrerenderHostRegistry knows that it can activate the prerendered
> page.
> 3. It informs every RenderFrameHostImpl(RFHI) of activation, and they
> will inform the corresponding documents on renderer sides.
> 4. These documents update their prerendering states and dispatch
> prerenderingchange events.
> 5. These documents inform the browser process that they finished
> activating.
> 6. The browser process releases binder policies. This should be done
> after step 5 because the renderer isn't meant to get these deferred
> messages before the prerenderingchange event is diepatched. But these
> Mojo message pipes are not channel-associated, once we grant those
> deferred binders and the interfaces are bound to the renderer, it
> might receives some deferred messages before CommitActivation arrives.
>
> The prerendered page is allowed to access kCancel and kUnexpected APIs
> in the prerenderingchange event, so RFHI may receive kCancel or
> kUnexpected binding requests between 4 and 6, which means we should
> loosen the Mojo capability control before firing this event.
>
> The decision of when to loose control has not been finalized, but at
> this point we can loosen the kCancel and kUnexpected polices in
> RenderFrameHostImpl::ActivateForPrerendering() for starting early
> testing.
>
> This CL implements this logic and adds a browser test for the
> GamepadMonitor interface, whose policy is kCancel, to ensure the
> change works.
>
> Bug: 1132752, 1186796
> Change-Id: Ib3da39f9cae6b1a46d08a64d8f41b5f5b50460c0
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2810422
> Commit-Queue: Lingqi Chi <lingqi@chromium.org>
> Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
> Reviewed-by: Matt Falkenhagen <falken@chromium.org>
> Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#874138}
Bug: 1132752, 1186796, 1198110
Change-Id: I8be5c672e7a81db261329bc807146c9d13f92bc9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2842625
Commit-Queue: Lingqi Chi <lingqi@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#875615}
This reverts commit a728ed6052.
Reason for revert:
All/PrerenderBrowserTest.GamepadMonitorAfterNavigation/WebContents
All/PrerenderBrowserTest.GamepadMonitorAfterNavigation/MPArch
are failing on linux-lacros-tester-rel
Example: https://ci.chromium.org/ui/p/chromium/builders/ci/linux-lacros-tester-rel/9034/overview
Original change's description:
> Prerender: Loosen Mojo capability control before firing
> prerenderingchange
>
> For prerendering, MojoBinderPolicyMapApplier wants to loosen the kCancel
> policy slightly before the activation is complete.
>
> The activation of a prerendered page follows the steps below.
> 1. The activation navigation to the prerendered page is committed.
> 2. PrerenderHostRegistry knows that it can activate the prerendered page.
> 3. It informs every RenderFrameHostImpl(RFHI) of activation, and they
> will inform the corresponding documents on renderer sides.
> 4. These documents update their prerendering states and dispatch
> prerenderingchange events.
> 5. These documents inform the browser process that they finished
> activating.
> 6. The browser process releases binder policies. This should be done
> after step 5 because the renderer isn't meant to get these deferred
> messages before the prerenderingchange event is diepatched. But these
> Mojo message pipes are not channel-associated, once we grant those
> deferred binders and the interfaces are bound to the renderer, it might
> receives some deferred messages before CommitActivation arrives.
>
> The prerendered page is allowed to access kCancel and kUnexpected APIs
> in the prerenderingchange event, so RFHI may receive kCancel or
> kUnexpected binding requests between 4 and 6, which means we should
> loosen the Mojo capability control before firing this event.
>
> The decision of when to loose control has not been finalized, but at
> this point we can loosen the kCancel and kUnexpected polices in
> RenderFrameHostImpl::ActivateForPrerendering() for starting early
> testing.
>
> This CL implements this logic and adds a browser test for the
> GamepadMonitor interface, whose policy is kCancel, to ensure the change
> works.
>
> Bug: 1132752, 1186796
> Change-Id: Ib3da39f9cae6b1a46d08a64d8f41b5f5b50460c0
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2810422
> Commit-Queue: Lingqi Chi <lingqi@chromium.org>
> Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
> Reviewed-by: Matt Falkenhagen <falken@chromium.org>
> Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#874138}
Bug: 1132752
Bug: 1186796
Change-Id: Icb14aa78708d99d93079ee29bfede536432d2caf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2837979
Auto-Submit: Christos Froussios <cfroussios@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Christos Froussios <cfroussios@chromium.org>
Owners-Override: Christos Froussios <cfroussios@chromium.org>
Cr-Commit-Position: refs/heads/master@{#874205}
prerenderingchange
For prerendering, MojoBinderPolicyMapApplier wants to loosen the kCancel
policy slightly before the activation is complete.
The activation of a prerendered page follows the steps below.
1. The activation navigation to the prerendered page is committed.
2. PrerenderHostRegistry knows that it can activate the prerendered page.
3. It informs every RenderFrameHostImpl(RFHI) of activation, and they
will inform the corresponding documents on renderer sides.
4. These documents update their prerendering states and dispatch
prerenderingchange events.
5. These documents inform the browser process that they finished
activating.
6. The browser process releases binder policies. This should be done
after step 5 because the renderer isn't meant to get these deferred
messages before the prerenderingchange event is diepatched. But these
Mojo message pipes are not channel-associated, once we grant those
deferred binders and the interfaces are bound to the renderer, it might
receives some deferred messages before CommitActivation arrives.
The prerendered page is allowed to access kCancel and kUnexpected APIs
in the prerenderingchange event, so RFHI may receive kCancel or
kUnexpected binding requests between 4 and 6, which means we should
loosen the Mojo capability control before firing this event.
The decision of when to loose control has not been finalized, but at
this point we can loosen the kCancel and kUnexpected polices in
RenderFrameHostImpl::ActivateForPrerendering() for starting early
testing.
This CL implements this logic and adds a browser test for the
GamepadMonitor interface, whose policy is kCancel, to ensure the change
works.
Bug: 1132752, 1186796
Change-Id: Ib3da39f9cae6b1a46d08a64d8f41b5f5b50460c0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2810422
Commit-Queue: Lingqi Chi <lingqi@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#874138}
This CL includes the following changes.
- Updates the final state of PrerenderHost when MojoBinderPolicyApplier
cancels prerendering.
- Records the interface that causes the cancellation and reports it to
UMA.
Bug: 1132752, 1126305
Change-Id: Ibc156d588424917c2a8f05478e386b272c6cffe8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2796850
Reviewed-by: Steven Holte <holte@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Lingqi Chi <lingqi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#870322}
For kUnexpected interface binders, we want to understand the situation
by checking crash reports.
When receiving an unexpected binding request, MojoBinderPolicyApplier
- Reports a bad mojom message to crash the corresponding renderer.
- Cancels the prerender.
Bug: 1141364
Change-Id: Ia332ccb14b723ce160c6514a7c8128e96c466c7d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2784660
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Commit-Queue: Lingqi Chi <lingqi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#867577}
This CL allows Prerender2 to partially loosen its binding policies by
switching MojoBinderPolicyApplier(MBPA) into the kPrepareToGrantAll
mode.
The Prerender activation flow requires Mojo capability control to
loosen kCancel and kUnexpected policies before Blink dispatches the
`prerenderingchange` event.
(https://docs.google.com/document/d/1_l1LDUALf8PbZIz5y_UYNGZmYCMKNpePDLBHn-gTsTM/)
Mojo capability control controls when and whether to bind a interface
with MBPA. Before this CL, MBPA only runs in two modes, one applies
pre-set policies strictly, and will cancel the current prerender if it
receives a kCancel/kUnexpected interface; the other ignores these
policies and runs all binders immediately.
To meet the new requirement, this CL introduces a new
mode, kPrepareToGrantAll. When running in this mode, MBPA only defers
non-kGrant binding requests but not cancels prerendering.
Bug: 1132752
Change-Id: Ie93eb7aba458f3e687649d6c3859feb44ccdfe20
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2726016
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Lingqi Chi <lingqi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#863697}
RenderFrameHostImpl
After https://chromium-review.googlesource.com/c/chromium/src/+/2689551,
RenderFrameHostImpl(RFHI) can access the correct prerendering state in
its constructor. So RFHI can decide whether to enable Mojo capability
control here according to the prerendering state.
This CL sets MojoBinderPolicyApplier in RFHI::ctor. It brings the
following benefits:
1. In prerendering pages, we can ensure that
BrowserInterfaceBrokerImpl(BIB) receives interface binders after
RFHI sets MojoBinderPolicyApplier, i.e., Mojo capability control is
enabled before BIB receives the first binding request.
2. It unifies the logic of setting MojoBinderPolicyApplier; RFHI sets it
in three different methods before this CL.
3. It guarantees every RenderFrameHostImpl in the prerendering frame
tree enables Mojo capability control. Before this CL, activating the
prerendering page could happen before RFHI::CommitNavigation(), which
fails `CHECK(policy_applier_);` in ReleaseMojoBinderPolicies().
Bug: 1132752, 1160611
Change-Id: Ie1bb0366fc01d3018ad7e6b52cff31152d000f78
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2738156
Commit-Queue: Lingqi Chi <lingqi@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#861494}
Same-origin prerendering and cross-origin prerendering should have
different Mojo binder policies to protect users' privacy.
Prerender2 plan to support only same-origin prerendering in the early
stage, so now all policies set for prerendering are for same-origin
prerendering.
This CL renames all policy-related *ForPrerendering functions to
*ForSameOriginPrerendering to make the intention clearer.
Bug: 1145976
Change-Id: Iad714876af22a29441071fcbbc62e0ae70bfa7bf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2726024
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Commit-Queue: Lingqi Chi <lingqi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#859301}
Prerender2 wants to defer running some interface binders so as to
control the capability of renderer processes in prerendering pages.
This CL creates MojoBinderPolicyApplier and adds it to
BrowserInterfaceBrokerImpl of prerendering frames to make it.
Bug: 1132752
Change-Id: I0777620c68eb0435611ab96e27bc3e56c4936029
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2629067
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Lingqi Chi <lingqi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#845087}
Some new features, such as prerendering, need to defer some binding
interface requests or stop the renderer when an unexpected mojo pipe is
requested to set up.
This CL introduces MojoBinderPolicyApplier that manages binding requests
and integrates it with BrowserInterfaceBroker.
Regarding the MojoBinderPolicyApplier, it should be initialized with a
predefined policy map. It decide the actions the applier takes when
handling incoming requests. Based on the predefined policies and the
current state, a MojoBinderPolicyApplier instance may take the following
actions:
1. Bind the given interface immediately. (kGrant or
`ResolveDeferredBinders` has been invoked)
2. Delay binding the interface until `ResolveDeferredBinders` is called.
(kDefer)
3. Call the cancelling closure. (kCancel)
4. Stop the renderer and collect some metrics for analysis. (kUnexpected)
Bug: 1132752
Change-Id: Ifdc2f0b27d2f4613274fe5c6e44ddb056a199509
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2513960
Commit-Queue: Lingqi Chi <lingqi@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#828609}
