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 also removes task_runner_util.h and task_runner_util_unittests.cc.
This is the last part of a chrome-wide refactor changing calls like
base::PostTaskAndReplyWithResult(task_runner[...] to calls like
task_runner->PostTaskAndReplyWithResult([...]
Bug: 1026641
Change-Id: I86e5b09ee5b62f55aa03c878102644a438f85301
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4062277
Commit-Queue: Sean Maher <spvw@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Owners-Override: Gabriel Charette <gab@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1078168}
All the callers are now on the UI thread, so remove all the locking and
complicated threading requirements. Do the same for PluginService.
Bug: 990013
Change-Id: Ie4dac75b4829825978d5873fd28f4ce75c14510b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3866812
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1058235}
Renames PepperPluginInfo to ContentPluginInfo, in order to reflect that
this struct no longer is used only with PPAPI.
The name ContentPluginInfo was chosen because the name PluginInfo is
overloaded already for 3 different types in Chromium. The name also
emphasizes that this type supports the //content layer specifically.
Most of this change is mechanical, with the following exceptions:
1. Some other names have been changed to drop references to Pepper, such
as renaming ContentClient::AddPepperPlugins() to
ContentClient::AddPlugins(). Note that Pepper-specific functions like
MakePepperPluginInfo() intentionally still mention Pepper.
2. Refactored PluginManager::UpdatePluginListWithNaClModules() to use
range-based "for" loops, instead of iterators.
Bug: 1344644
Change-Id: I9b8596f6a53593ed7c4b7e06a266b57c82b0d9bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3835746
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: K. Moon <kmoon@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1040827}
This CL adds newer functions that check safety of plugins by
BrowserContext, and not renderer_process_id.
This is needed as we want to set pdfs loaded from history service to
open in the browser by default, which requires this check. The pdfs do
not have an associated renderer process, and the check only requires a
BrowserContext anyway.
Bug: 1352120
Change-Id: I232071529b62b0213e4e760796596f6b07fd5b83
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3849622
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Min Qin <qinmin@chromium.org>
Commit-Queue: Rohit Bhatia <bhatiarohit@google.com>
Reviewed-by: Xinghui Lu <xinghuilu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1038995}
Registers the PDF plugin even when PPAPI is disabled. This requires two
main changes:
1. Allowing use of PepperPluginInfo, regardless of the ENABLE_PPAPI
buildflag. This required making the "internal_entry_points" member
conditional.
2. Registering the PDF plugin in ChromeContentClint::AddPepperPlugins(),
regardless of the ENABLE_PPAPI buildflag.
This change also makes several other improvements to PepperPluginInfo:
1. Uses default member initializers, greatly reducing the need for
conditional compilation in pepper_plugin_info.cc.
2. Adds a move constructor, since there's already a copy constructor.
3. Drops the "is_external" field, which became dead code in
crrev.com/1037953.
Finally, this change inlines ComputeBuiltInPlugins(), since the
remaining code is relatively straightforward.
Fixed: 1306610
Change-Id: Ia8927b632f31f53c23a965766c2d8946b5062b16
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3837314
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: K. Moon <kmoon@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1038300}
Puts all remaining uses of PpapiPluginProcessHost behind the
ENABLE_PPAPI buildflag.
As all the existing tests for PluginServiceImpl depend on
PpapiPluginProcessHost, also adds a new test that does not.
Also reorganizes plugin_service_impl.h's include order to follow the
style guide more closely.
Bug: 1306610
Change-Id: Ia9ee1e660def3ed0b790539fe3995938770170bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3840473
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: K. Moon <kmoon@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1036854}
Separates sources for plugin support from sources for PPAPI support in
BUILD.gn files under the //content tree.
Note that enable_plugins=true, enable_ppapi=false should compile, but
does not link. This is fine, as this configuration isn't supported yet.
Note that compiling plugin_service_impl.cc with enable_ppapi=false
requires some additional changes, as some includes are conditional on
BUILDFLAG(ENABLE_PPAPI).
Note that ShellPluginServiceFilter doesn't actually depend on PPAPI, so
the dependency simply can be dropped
This change also refactors //content/common/BUILD.gn to follow the more
common pattern of adding sources when the feature is enabled, rather
than removing sources when the feature is disabled.
Bug: 1306610
Change-Id: I5ec7829a9c9bae8003d4537896ade0b646f4af6a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3811451
Auto-Submit: K. Moon <kmoon@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: K. Moon <kmoon@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1032221}
Removes the CountPpapiPluginProcessesForProfile() API from
PluginService. This API is only used externally by
plugin_response_interceptor_url_loader_throttle_browsertest.cc for
counting PDF plugin processes, but is unfit for this purpose ever since
the PDF viewer migrated from Pepper (crbug.com/702993).
This API is still used internally by PluginServiceImpl, but an anonymous
free function in plugin_service_impl.cc suffices.
Bug: 1306610
Change-Id: I055c5ed2d2c192c859c594a100faeb6dc8bdfc3b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3789927
Reviewed-by: Nigi <nigi@chromium.org>
Reviewed-by: Tommy Nyquist <nyquist@chromium.org>
Commit-Queue: K. Moon <kmoon@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1029489}
Removes unused parameters from PluginServiceFilter::IsPluginAvailable().
Note that because Blink caches plugin availability per process, it's not
correct to vary plugin availability on most of these parameters, which
resulted in bugs like crbug.com/1261758.
Also adds back ChromePluginServiceFilterTest cases for
IsPluginAvailable(), as crrev.com/833469 dropped all of the existing
tests.
Bug: 850278
Change-Id: I82f15c476ac93bb0c1cb719c640ca068374f1b42
Fixed: 1261922
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3248711
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: K. Moon <kmoon@chromium.org>
Cr-Commit-Position: refs/heads/main@{#935617}
This CL was generated by using tools/git/move_source_file.py to change
the includes for those files:
base/bind_post_task.h
base/deferred_sequenced_task_runner.h
base/post_task_and_reply_with_result_internal.h
base/sequenced_task_runner.h
base/sequenced_task_runner_helpers.h
base/single_thread_task_runner.h
base/task_runner.h
base/task_runner_util.h
base/updateable_sequenced_task_runner.h
Then formatted using "git cl format". DEPS files were fixed with a
simple search and replace script.
Bug: 1255932
Change-Id: I0d9b5ddd9260fde5e4581e6c6e0080bdb0ed2c44
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3209175
Reviewed-by: Gabriel Charette <gab@chromium.org>
Owners-Override: Gabriel Charette <gab@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/main@{#929867}
Don't include it if it is not needed, especially since
web_contents_impl.h is a big header. Add other headers that
web_contents_impl.h transitively included to fix the build.
Bug: 242216
Change-Id: I62050b638b402a32a5a6846a1240228b29b879dc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3033578
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#902511}
This change modifies base::ASCIIToUTF16 to cause compilation errors when
it is used with a string constant outside of tests. Instead, callers
should just use a UTF16 literal (u"...") instead.
Bug: 1189439
Change-Id: If6650eb69ce7de5c5f371b6b6003705aaf508393
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2826458
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#873352}
They were on the IO thread to avoid deadlocks with NPAPI plugins, but we don't have that anymore.
Currently this is off by default behind a feature flag. I have tried to minimize the churn in the code to enable this. Some places where it would involve too much duplication or refactoring I've kept with PostTasks from UI to UI thread. Once this is enabled by default then I'll simplify all the callsites.
Bug: 904556
Change-Id: Ib664d644e0af016d5736348218bcc38cb79341f8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2806425
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Owners-Override: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#870614}
This CL removes network::CrossOriginReadBlockingExceptionForPlugin and
content::RenderProcessHostImpl::AddCorbExceptionForPlugin (and any other
code these removals transitively enable).
The CL also needs to adjust how the test plugins work:
1. Changing PluginServiceImpl::FindOrStartPpapiPluginProcess to use the
NetworkService::AddAllowedRequestInitiatorForPlugin mechanism for
the test plugin (the same mechanism that is used for the PDF plugin).
This is needed to make sure that the test plugin continues passing
request_initiator_origin_lock checks and CORB checks.
This change requires that FindOrStartPpapiPluginProcess always sees a
non-null `origin_lock` - this is accomplished by isolating all
non-NaCl plugins in IsOriginIsolatedPepperPlugin (also avoiding
isolation in presence of the --ppapi-in-process switch used by some
tests).
2. Removing CORB/Flash-specific tests and supporting test code,
or tweaking them to simulate PDF-related functionality.
Fixed: 1134401
Change-Id: Iac3579b2f3c66ac434583fcbb3119ac6857ec436
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2560827
Reviewed-by: Raymes Khoury <raymes@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Weilun Shi <sweilun@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#834542}
The second CL in implementing origin-/site-keying of SiteInstances.
https://crbug.com/1085275/#c2 lists the sequence of CLs and what each
will accomplish.
This CL is a refactor to introduce the ProcessLock class to replace
the GURLs returned by GetOriginLock() and related functions.
It also combines some argument lists that take both a SiteURL and a
LockURL and instead uses SiteInfo or ProcessLock. One notable example
is RenderProcessHostImpl::IsSuitableHost().
Bug: 1067389, 846155
Change-Id: I3c6f67f2bf6f1ce3ed2bc394dbd92827ebd8a50a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2246923
Commit-Queue: James MacLean <wjmaclean@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Aaron Colwell <acolwell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#788226}
Note to QA: This CL is purely mechanical and shouldn't be blamed
for future regressions on touched files.
This is a follow-up to https://chromium-review.googlesource.com/c/chromium/src/+/2211138
which already removed all usage using content::BrowserThread.
Hence this script now matches unqualified BrowserThread:: without
risking having "content::" be selected as "traits_before" by the regex
(ran on same revision as step #1).
content:: is now always added if outside namespace content {}
(deleting unused using content::BrowserThread; decls)
Script @ https://crbug.com/1026641#c92
(will TBR fdoray@ post-review for mechanical change)
TBR=fdoray@hchromium.org
AX-Relnotes: n/a.
Bug: 1026641
Change-Id: I51ae2f83eb17d19b54563fd9b4fc040d2aa0c948
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2212469
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: François Doray <fdoray@chromium.org>
Cr-Commit-Position: refs/heads/master@{#772458}
In some scenarios (e.g. http range requests for linearized PDFs) the PDF
plugin may need to initiate requests on behalf of the PDF's origin.
Such requests are currently proxied by the renderer process hosting the
plugin (i.e. the renderer hosting the PDF extension -
mhjfbmdgcfjbbpaeojofohoefgiehjai) and therefore go through
URLLoaderFactory that is locked via request_initiator_site_lock to a
different origin (i.e. the origin of the PDF extension, rather than the
origin of the website that hosts the PDF file).
Before this CL, such requests would be classified by
CorsURLLoaderFactory::IsSane and
VerifyRequestInitiatorLockWithPluginCheck as incorrect and possibly
malicious. After this CL, the request_initiator checks are relaxed by
PluginServiceImpl::FindOrStartPpapiPluginProcess using a new mechanism
similar to AddCorbExceptionForPlugin exemption available for Flash.
We don't want to relax request_initiator_site_lock checks for renderer
processes hosting arbitrary origins from the web, so as a
defense-in-depth the CL adds a CHECK to FindOrStartPpapiPluginProcess
that verifies the origin lock of the renderer process that is granted
the extra capabilities.
Relevant tests:
- ChromeFindRequestManagerTest.FindInChunkedPDF (tests that range
request do not result in a request initiator lock mismatch)
- PDFExtensionTest.EnsureInternalPluginDisabled (tests that the PDF
plugin may only be embedded in trustworthy contexts)
- PDFExtensionTest.RedirectsFailInPlugin (the 'noRedirectsSucceed' testcase
tests non-range requests initiated by the PDF plugin)
Bug: 1027173
Tbr: creis@chromium.org
Tbr: nasko@chromium.org
Tbr: yhirano@chromium.org
Change-Id: I9a8f284a8927b1230c5088f8c46aca118e934c8d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2036558
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#737939}
This reverts commit ad44950ea6.
Reason for revert: Test flakiness reported in https://crbug.com/1047941
Original change's description:
> Relax request_initiator_site_lock checks for PDF plugin.
>
> In some scenarios (e.g. http range requests for linearized PDFs) the PDF
> plugin may need to initiate requests on behalf of the PDF's origin.
> Such requests are currently proxied by the renderer process hosting the
> plugin (i.e. the renderer hosting the PDF extension -
> mhjfbmdgcfjbbpaeojofohoefgiehjai) and therefore go through
> URLLoaderFactory that is locked via request_initiator_site_lock to a
> different origin (i.e. the origin of the PDF extension, rather than the
> origin of the website that hosts the PDF file).
>
> Before this CL, such requests would be classified by
> CorsURLLoaderFactory::IsSane and
> VerifyRequestInitiatorLockWithPluginCheck as incorrect and possibly
> malicious. After this CL, the request_initiator checks are relaxed by
> PluginServiceImpl::FindOrStartPpapiPluginProcess using a new mechanism
> similar to AddCorbExceptionForPlugin exemption available for Flash.
>
> We don't want to relax request_initiator_site_lock checks for renderer
> processes hosting arbitrary origins from the web, so as a
> defense-in-depth the CL adds a CHECK to FindOrStartPpapiPluginProcess
> that verifies the origin lock of the renderer process that is granted
> the extra capabilities.
>
> Relevant tests:
> - ChromeFindRequestManagerTest.FindInChunkedPDF (tests that range
> request do not result in a request initiator lock mismatch)
> - PDFExtensionTest.EnsureInternalPluginDisabled (tests that the PDF
> plugin may only be embedded in trustworthy contexts)
> - PDFExtensionTest.RedirectsFailInPlugin (the 'noRedirectsSucceed' testcase
> tests non-range requests initiated by the PDF plugin)
>
> Bug: 1027173
> Change-Id: Ib5111fd7a5d5b31727a9754c46c316e75def5143
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1986923
> Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
> Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
> Reviewed-by: Nasko Oskov <nasko@chromium.org>
> Reviewed-by: Charlie Reis <creis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#737503}
TBR=creis@chromium.org,nasko@chromium.org,yhirano@chromium.org,lukasza@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: 1027173
Change-Id: Icc030c676025c042b7647f5ac265511bbb6f25cd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2035857
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#737832}
In some scenarios (e.g. http range requests for linearized PDFs) the PDF
plugin may need to initiate requests on behalf of the PDF's origin.
Such requests are currently proxied by the renderer process hosting the
plugin (i.e. the renderer hosting the PDF extension -
mhjfbmdgcfjbbpaeojofohoefgiehjai) and therefore go through
URLLoaderFactory that is locked via request_initiator_site_lock to a
different origin (i.e. the origin of the PDF extension, rather than the
origin of the website that hosts the PDF file).
Before this CL, such requests would be classified by
CorsURLLoaderFactory::IsSane and
VerifyRequestInitiatorLockWithPluginCheck as incorrect and possibly
malicious. After this CL, the request_initiator checks are relaxed by
PluginServiceImpl::FindOrStartPpapiPluginProcess using a new mechanism
similar to AddCorbExceptionForPlugin exemption available for Flash.
We don't want to relax request_initiator_site_lock checks for renderer
processes hosting arbitrary origins from the web, so as a
defense-in-depth the CL adds a CHECK to FindOrStartPpapiPluginProcess
that verifies the origin lock of the renderer process that is granted
the extra capabilities.
Relevant tests:
- ChromeFindRequestManagerTest.FindInChunkedPDF (tests that range
request do not result in a request initiator lock mismatch)
- PDFExtensionTest.EnsureInternalPluginDisabled (tests that the PDF
plugin may only be embedded in trustworthy contexts)
- PDFExtensionTest.RedirectsFailInPlugin (the 'noRedirectsSucceed' testcase
tests non-range requests initiated by the PDF plugin)
Bug: 1027173
Change-Id: Ib5111fd7a5d5b31727a9754c46c316e75def5143
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1986923
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#737503}
Before this CL, the PDF plugin process would enforce that it may only be
embedded inside the PDF extension's origin
(mhjfbmdgcfjbbpaeojofohoefgiehjai) and inside chrome://print. After
this CL, this enforcement is done in the browser process instead. The
earlier enforcement helps add security assertions that follow-up CLs may
depend on - for example see:
https://crrev.com/c/1986923/15/content/browser/plugin_service_impl.cc#211
The already existing PDFExtensionTest.EnsureInternalPluginDisabled test
makes sure that the PDF plugin may not be embedded in a data: URL.
Bug: 1027173
Change-Id: I0d1d47d9dee7de92d1f3cbb44a72d38b14236f69
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2003262
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#733121}
This reduces the number of preprocessor tokens in
content_browser_client.h from 1,335,281 to 754,474. Since this is a
widely included file, reducing build times a fair bit (see bug).
TBR=tsepez for content/browser/child_process_security_policy_*
Bug: 1014009
Change-Id: Id3c2de29f5b08cab80820d01aff722afeb1618e6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1857126
Commit-Queue: Hans Wennborg <hans@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Camille Lamy <clamy@chromium.org>
Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#706388}
This switches to using BrowserContext instead of ResourceContext for
PluginService and plugin_utils.cc. This required moving
PluginRegistryImpl, PluginInfoHostImpl, and
RenderFrameMessageFilter::OnGetPluginInfo to run on the UI thread.
This eliminates one of the major dependencies of extensions::InfoMap.
Bug: 980774
Change-Id: I7b26c5b40dc8b98c518339b771249ef16e6ec856
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1730093
Commit-Queue: Clark DuVall <cduvall@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#684082}
*** Note: There is no behavior change from this patch. ***
The PostTask APIs will shortly be changed to require all tasks to explicitly
specify their thread affinity, i.e., whether the task should run on the thread
pool or a specific named thread such as a BrowserThread. This patch updates all
call sites with thread affinity annotation. We also remove the "WithTraits"
suffix to make the call sites more readable.
Before:
// Thread pool task.
base::PostTaskWithTraits(FROM_HERE, {...}, ...);
// UI thread task.
base::PostTaskWithTraits(FROM_HERE, {BrowserThread::UI, ...}, ...);
After:
// Thread pool task.
base::PostTask(FROM_HERE, {base::ThreadPool(), ...}, ...);
// UI thread task.
base::PostTask(FROM_HERE, {BrowserThread::UI, ...}, ...);
This patch was semi-automatically prepared with these steps:
1. Patch in https://chromium-review.googlesource.com/c/chromium/src/+/1635827
to make thread affinity a build-time requirement.
2. Run an initial pass with a clang rewriter:
https://chromium-review.googlesource.com/c/chromium/src/+/1635623
3. ninja -C out/Debug | grep 'requested here' | cut -d: -f1-3 | sort | \
uniq > errors.txt
4. while read line; do
f=$(echo $line | cut -d: -f 1)
r=$(echo $line | cut -d: -f 2)
c=$(echo $line | cut -d: -f 3)
sed -i "${r}s/./&base::ThreadPool(),/$c" $f
done < errors.txt
5. GOTO 3 until build succeeds.
6. Remove the "WithTraits" suffix from task API call sites:
$ tools/git/mffr.py -i <(cat <<EOF
[
["PostTaskWithTraits", "PostTask"],
["PostDelayedTaskWithTraits", "PostDelayedTask"],
["PostTaskWithTraitsAndReply", "PostTaskAndReply"],
["CreateTaskRunnerWithTraits", "CreateTaskRunner"],
["CreateSequencedTaskRunnerWithTraits", "CreateSequencedTaskRunner"],
["CreateUpdateableSequencedTaskRunnerWithTraits", "CreateUpdateableSequencedTaskRunner"],
["CreateSingleThreadTaskRunnerWithTraits", "CreateSingleThreadTaskRunner"],
["CreateCOMSTATaskRunnerWithTraits", "CreateCOMSTATaskRunner"]
]
EOF
)
This CL was uploaded by git cl split.
R=boliu@chromium.org, tsepez@chromium.org
Bug: 968047
Change-Id: I346372d16a3856186ea74d14e0dd8a12f7cacae5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1729589
Commit-Queue: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Auto-Submit: Sami Kyöstilä <skyostil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#683554}
This is a reland of 5fdbf6eb24
Original change's description:
> Click to Open PDF: Improve first-time IFRAME throttle behavior
>
> Currently, the IFRAME throttle doesn't always work on first-time use,
> when the Chrome process is first started. This is because the IFRAME
> throttle itself doesn't trigger the plugin list load.
>
> This CL updates the throttle to also trigger the plugin list load
> itself (only if it hasn't been loaded already), and should make the
> behavior less flaky.
>
> Bug: 924823
> Change-Id: If51e85bf2d7005af1a5a825279388dd6d9324409
> Reviewed-on: https://chromium-review.googlesource.com/c/1452771
> Commit-Queue: Lei Zhang <thestig@chromium.org>
> Reviewed-by: Nasko Oskov <nasko@chromium.org>
> Reviewed-by: Camille Lamy <clamy@chromium.org>
> Reviewed-by: Lei Zhang <thestig@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#629878}
TBR=
Bug: 924823
Change-Id: I717d5f9d3e7ff902b1adbc6656666fc9c4395dab
Reviewed-on: https://chromium-review.googlesource.com/c/1464654
Commit-Queue: Tommy Li <tommycli@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#632281}
This reverts commit 5fdbf6eb24.
Reason for revert: Introduced tests are failing
Original change's description:
> Click to Open PDF: Improve first-time IFRAME throttle behavior
>
> Currently, the IFRAME throttle doesn't always work on first-time use,
> when the Chrome process is first started. This is because the IFRAME
> throttle itself doesn't trigger the plugin list load.
>
> This CL updates the throttle to also trigger the plugin list load
> itself (only if it hasn't been loaded already), and should make the
> behavior less flaky.
>
> Bug: 924823
> Change-Id: If51e85bf2d7005af1a5a825279388dd6d9324409
> Reviewed-on: https://chromium-review.googlesource.com/c/1452771
> Commit-Queue: Lei Zhang <thestig@chromium.org>
> Reviewed-by: Nasko Oskov <nasko@chromium.org>
> Reviewed-by: Camille Lamy <clamy@chromium.org>
> Reviewed-by: Lei Zhang <thestig@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#629878}
TBR=nasko@chromium.org,thestig@chromium.org,tommycli@chromium.org,clamy@chromium.org
Change-Id: Icb6d2acff0ad9d3bcc9072bf3e6ca42d653f27a3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 924823, 929819
Reviewed-on: https://chromium-review.googlesource.com/c/1459339
Reviewed-by: Karan Bhatia <karandeepb@chromium.org>
Commit-Queue: Karan Bhatia <karandeepb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#630041}
It only has one non-test caller, and that caller always passes in a
valid |use_stale| parameter. Update the unit tests to pass in the
parameter as well. After that, change it from an out parameter to the
return value.
Change-Id: Ia7862d74363b052c18ed9f37d4253c5f515f1d5f
Reviewed-on: https://chromium-review.googlesource.com/c/1456987
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#630011}
Currently, the IFRAME throttle doesn't always work on first-time use,
when the Chrome process is first started. This is because the IFRAME
throttle itself doesn't trigger the plugin list load.
This CL updates the throttle to also trigger the plugin list load
itself (only if it hasn't been loaded already), and should make the
behavior less flaky.
Bug: 924823
Change-Id: If51e85bf2d7005af1a5a825279388dd6d9324409
Reviewed-on: https://chromium-review.googlesource.com/c/1452771
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Camille Lamy <clamy@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#629878}
