Currently, there is no default implementation of the federated identity
delegates in content/browser. In order to make FedCM work in headless,
this CL moves the in-memory delegate implementation from content/shell
to content/browser.
Bug: 336561988
Change-Id: I5097f86c76bcd5bb41193ef14f16d1b2f0eef6a7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5740871
Reviewed-by: Nicolás Peña <npm@chromium.org>
Commit-Queue: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1333637}
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}
- Removes the awkward GetManagerForTest() from cache, by
content-exporting BrowserContextImpl, so the impl can be used in
various test targets (context:
https://crrev.com/c/4245857/comment/7c10dda8_67e6a8f1/).
- Asserts the APIs on cache can only accessed on UI thread (intended).
- RenderWidgetHostView::CopyFromSurface will be used to ask for
a screenshot of the current WebContent's view. This method does
not guarantee that the callback is executed on the same thread
(https://crbug.com/1309124 and https://crrev.com/c/3782813). If we
don't assert that these methods are accessed on UIThread, the
sequence checker in the SupportUserData will fail because
NavigationEntry are created on the UIThread.
- Removes unused headers.
Bug: 1415332, 1413521
Low-Coverage-Reason: DCHECKs will be tested in browsertests.
Change-Id: I1903d1c84a9787a348dadecf3a7d1ef6546f0828
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4393402
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: William Liu <liuwilliam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1127188}
Introduce NavigationEntryScreenshot, which preserves a screenshot on the
current NavigationEntry when the user is navigating away from it. The
stored screenshot will later be used to present the user with a preview,
when the user navigates back to this page.
The caching mechanism is composed of the screenshot, the cache and a
global manager. The global manager lives on the BrowserContext and is
responsible for memory budgeting. The cache lives on the primary
NavigationController which owns the NavigationEntry where the
screenshot is stashed.
This CL contains the impl of caching, retrieving and eviction of the
screenshots with unittests. The cache is not integrated with the navigation thus no browsertest.
The code resides in `//content/browser/renderer_host/` because no need
to access WebContents.
[Updated] DD/Explainer (chromium access): https://docs.google.com/document/d/1-7TatVjSL4n-RNyvN_MWdFoOiR6YJ1BjvJKgvym_ArU
Feature EngDoc: https://docs.google.com/document/d/1H99XZHdAWNfbfboHbGdMB97k81AzAxVtPSizAjO2Poc/
PRD (google access): https://docs.google.com/document/d/1JMWzArv0VR-G4xx3a5ku8N5np8mDeGSuvR95kZc8ynY/
Bug: 1415332, 1413521
Change-Id: Icc3b2aa7b5b36ed460ad2ddd1ff5f645a38d2835
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4245857
Reviewed-by: Kyle Charbonneau <kylechar@chromium.org>
Commit-Queue: William Liu <liuwilliam@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1125127}
This CL split the core, interceptor-independent parts of
PrefetchUrlLoaderInterceptor into prefetch_url_loader_helper.h/cc.
To remove dependencies to `PrefetchURLLoaderInterceptor`,
this CL injects GetPrefetchOriginProber/CopyIsolatedCookies
in unit tests via `TestPrefetchService`
instead of via `TestPrefetchURLLoaderInterceptor`.
This CL doesn't change the behavior.
Bug: 1422820
Change-Id: If091ddb511f6631b6f5769bca2037bd46c8b835f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4150615
Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org>
Reviewed-by: Max Curran <curranmax@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Lingqi Chi <lingqi@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1122886}
Use the new ability to write typed messages into the untyped and untyped
into typed to eliminate WriteIntoTrace(TracedValue) /
WriteIntoTrace(TracedProto) duplicated methods in //content.
After this patch, all key //content types listed below now have
corresponding proto messages (with DebugAnnotation support) and
WriteIntoTrace(TracedValue) methods have been removed:
- BrowserContext
- BrowsingContextState
- FrameTreeNode
- NavigationRequest
- RenderFrameHost
- RenderFrameProxyHost
- RenderViewHost
- SiteInstance
- SiteInstanceGroup
- GlobalRenderFrameHostId
This patch also adds a few `const` qualifiers to the appropriate methods
in //content to ensure that all WriteIntoTrace methods can be marked as
const.
R=rakina@chromium.org
Bug: 1137154
Change-Id: I306e7619f594e2a02ca24183720714f234661ff4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3540169
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Alex Ilin <alexilin@chromium.org>
Commit-Queue: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#984436}
This CL introduces the classes
WebrtcVideoPerfReporter
WebrtcVideoPerfRecorder
WebrtcVideoPerfHistory
The Reporter sends stats from the render process over mojo
to the Recorder in the browser process. The Recorder
keeps track of the current encode and decode stream configuration
and forwards the data to the History class.
History verifies that the stats look okay and persists to the local
database. History also retrieves stats from the database that are
used in order to predict if a certain configuration will be smooth
or not.
This CL implements functionality needed for the WebRTC
MediaCapabilities implementation. The binary size will therefore
be increased. I will do a follow-up CL that the reuses the
PendingOperation code that is shared between VideoDecodeStatsDBImpl
and WebrtcVideoStatsDBImpl.
Bug: chromium:1187565
Change-Id: I6588299611e591ab318e6ebe9d9bae825f9dd09e
Binary-Size: Size increase is unavoidable (see above).
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3443426
Reviewed-by: Matthew Denton <mpdenton@chromium.org>
Reviewed-by: Henrik Boström <hbos@chromium.org>
Reviewed-by: Chrome Cunningham <chcunningham@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Johannes Kron <kron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#971146}
* Rename BrowserContext::Impl into BrowserContextImpl
* Add static BrowserContextImpl::From(BrowserContext*)
This avoids content/ internal users to define in the content/public
browser_context.h new "friend" function, in order to access the
implementation from within content/
In the future, BrowserContext will be a pure interface, implemented by a
BrowserContextImpl. So, this is equivalent to the "future" possibility
of doing static_cast<BrowserContext*>, but available to today.
This is similar to what we did with the
NavigationRequest/NavigationHandle class deduplication with
NavigationRequest::From(NavigationHandle*).
Practically, this will avoid patch:
https://chromium-review.googlesource.com/c/chromium/src/+/3443426/16
From forward declaring RenderFrameHostImpl* and some content::internal
namespace.
Bug: https://crbug.com/1179776
Change-Id: I33baeca3f70ed9bb791f7a50a4795546f46fbae8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3461652
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#971109}
Before this CL, //content/browser/browser_context.cc would rely on
base::SupportsUserData to simulate 10+ fields of BrowserContext. The
motivation for this was to hide //content-internal details (e.g. the
fields and their types) from //content/public API (e.g. from the
declaration of the BrowserContext class).
After this CL, explicit fields are used while still being hidden from
//content/public API behind a private, fwd-declared Impl class.
Motivation:
- Removing the SupportsUserData dependency is a necessary step toward
migration to separate BrowserContext, BrowserContextImpl and
BrowserContextDelegate classes.
- Explicit fields are easier to read and use (when coding or when
using a debugger).
Bug: 1179776
Change-Id: Ifdc3ff1d7b945678fa0a915af780c9631c998058
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2706279
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Chrome Cunningham <chcunningham@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#868166}
