If our logic is correct, this should be a no-op. That would imply that
the state-data in browser/renderer gets out of sync.
The browser and renderer have difference classes to represent
PageLifecycleState:
- blink::mojom::PageLifecycleStatePtr
- mojom::blink::PageLifecycleStatePtr
so this has to be a template for it to work in both.
Bug: 1234634
Change-Id: If88398f594a108edac0dc4e8b701a79645b1d1fe
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3256289
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Fergal Daly <fergal@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941575}
As discussed in https://bit.ly/3qtrn9s we want to use gfx::PointF for
scroll offset (out of blink renderer) and gfx::Vector2dF for scroll
delta, instead of gfx::Vector2dF for both, for the following purposes:
1. To make it easier to do the correct thing: passing blink scroll
position (currently using FloatPoint, will be changed to gfx::PointF)
to out-of-blink scroll offset (and vice versa); and to make it
difficult to do the incorrect thing: passing blink scroll offset [1]
to out-of-blink scroll offset. Without this CL, the incorrect thing
would be easier to do than the correct thing because of the data
type mismatches.
2. We can better distinguish scroll offset and scroll delta with
different data types.
3. Make it consistent to use gfx::Point[F] for absolute scroll offsets
throughout Chromium.
[1] See third_party/blink/core/layout/README.md for detailed explanation
for of scroll position and scroll offset in blink renderer.
Bug: 738465
Change-Id: Ic9ac9658b8f3154514608ef4039780d0f20883bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3267944
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Kentaro Hara <haraken@chromium.org>
Owners-Override: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941498}
These values will also be used to fetch trusted scoring signals in
another CL. Sellers need to know the actual ad URLs to implement
blocklists.
While we expect these URLs to be primarily useful when fetching scoring
signals, doing so implicitly exposes them to scoreAd() method, so we
should explicitly expose them as well, so if sellers just need the URLs
in their Javascript, they aren't forced to fetch an extra scoring signal
JSON file.
In terms of privacy of bidders, these are URLs that have been offered
by bidders that have generated bids, so the seller only learns about
InterestGroup render URLs for URLs that bidders have made bids for.
Bug: 1265257
Change-Id: I1e0c18a1f15d46eac8dd52ce540a29b09f104ca2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3270070
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Maksim Orlovich <morlovich@chromium.org>
Commit-Queue: Matt Menke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941386}
Adds a temporary workaround for some flakes we're seeing in WebGL
conformance tests on ChromeOS VMs. This forces the first test in a shard
to be retried on failure if running on a ChromeOS VM since we've seen
some flaky GPU process startup issues.
Bug: 1079244
Change-Id: I8d9e2c777d8294cb781cb53b86b727cf5f521834
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3278711
Commit-Queue: Brian Sheedy <bsheedy@chromium.org>
Auto-Submit: Brian Sheedy <bsheedy@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941385}
The flags have been renamed to make it clear that they only
apply to Windows (see associated bug).
If you're reviewing this CL, please verify your code's usage
of the flag to ensure that the behavior is as intended. Thanks!
This CL was uploaded by git cl split.
R=altimin@chromium.org
Bug: 1244149
Change-Id: Ic762c8865ec979c605e7abb0699a706957323874
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3279383
Auto-Submit: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941348}
This reverts commit 7c47ce7c55.
Reason for revert: Hit submit too quickly, still needs histograms.xml review.
Original change's description:
> Implement OAC Process Count Overhead Metric.
>
> This CL introduces a "process count overhead" metric, based on an
> estimate of how many additional processes are needed for
> OriginAgentCluster (OAC). It's an estimate since we can't control for
> all variables, like the coalescing of SiteInstances from multiple
> BrowsingInstances in a single RenderProcess, or the effects of all
> possible configurations of the SiteInfo parameters.
>
> The estimate is based on counting the total number of HTTPS
> SiteInstances (OAC is only used for HTTPS) by seeing how many unique
> SiteInfos they generate in each BrowsingInstance, then converting each
> SiteInfo to its non-OAC equivalent and counting again, and comparing
> the two counts. The difference is the overhead estimate. This value
> should only be reported for users with cross-process OAC enabled.
>
> Basically, this is a best effort approach because knowing the exact
> process count requires too much knowledge of process creation history.
> It ignores process sharing, which is usually (but not always) an upper
> bound on the actual overhead.
>
> Bug: 1171269
> Change-Id: I31781bc8dedcb7c4849776d82aacb2890f255142
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3182871
> Reviewed-by: Charlie Reis <creis@chromium.org>
> Reviewed-by: Caitlin Fischer <caitlinfischer@google.com>
> Reviewed-by: Tom Sepez <tsepez@chromium.org>
> Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
> Commit-Queue: W. James MacLean <wjmaclean@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#941335}
TBR=creis@chromium.org,tsepez@chromium.org,alexmos@chromium.org,lizeb@chromium.org,wjmaclean@chromium.org,caitlinfischer@google.com,chromium-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: Icc51b7a8d4b894f968c9805baa2cafaa73cdd385
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 1171269
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3278353
Reviewed-by: W. James MacLean <wjmaclean@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Katie Dektar <katie@chromium.org>
Owners-Override: Katie Dektar <katie@chromium.org>
Commit-Queue: W. James MacLean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941341}
This reverts commit 865c12f322.
Reason for revert: attempting reland.
Original change's description:
> Revert "[content] Standardize "message loop starts" signal across Desktop, Android, and browser tests"
>
> This reverts commit 67bcc9c2d1.
>
> Reason for revert: suspect for crbug.com/1269720 though I can't
> explain why it would cause that failure (and that one alone)
>
> Original change's description:
> > [content] Standardize "message loop starts" signal across Desktop, Android, and browser tests
> >
> > And make content (BrowserMainLoop) responsible for running the
> > integration test hook (`MainFunctionParams::ui_task`) instead of each
> > BrowserMainParts impl doing so slightly differently.
> >
> > This is mostly a no-op but for some BrowserMainParts which did more work
> > after running `ui_task`, that work will now happen before `ui_task`
> > runs.
> >
> > Metrics recording in //chrome is centralized at the end of
> > PreMainMessageLoopRun on all platforms.
> >
> > Standardizing cross-platform ordering avoids forcing 4 awkward ordering
> > requirements in
> > https://chromium-review.googlesource.com/c/chromium/src/+/2892251 (see
> > diff of TODOs no longer needed after rebasing on this CL :
> > https://chromium-review.googlesource.com/c/chromium/src/+/2892251/44..47)
> >
> > This also allows getting rid of a force function in
> > startup_metrics_browsertest.cc to pretend some metrics were logged
> > (they now actually are without interfering with the product code).
> >
> > Part of the uncovered portion of BrowserMainLoop::PreMainMessageLoopRun
> > in browser tests was the part setting disallowance to do Blocking/Wait
> > operations on main thread. Unfortunately adding this ban breaks many
> > tests, browser_test_base.cc explicitly inverts those new thread
> > restrictions in this CL with a TODO to bring them in-line with the
> > product restrictions.
> >
> > BrowserMainParts overrides can get also rid of their |run_message_loop_|
> > variable when moving handling of the browser test hook (`ui_task`) in
> > WillRunMainMessageLoop(). And in a follow-up they will be updated to
> > only receive a `bool is_integration_test` from CreateBrowserMainParts
> > instead of the full MainFunctionParams which none use beyond that bool.
> >
> > ContentBrowserTestSanityTests verify that browser test bodies still run
> > as expected with this change.
> >
> > Bug: 1175074, 1253634
> > Change-Id: Ib757a02bbd982ef2b1132e2791e8ec1ce0305038
> > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3187153
> > Reviewed-by: Alexander Timin <altimin@chromium.org>
> > Reviewed-by: Sean Topping <seantopping@chromium.org>
> > Reviewed-by: Scott Violet <sky@chromium.org>
> > Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
> > Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
> > Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
> > Reviewed-by: Bo <boliu@chromium.org>
> > Commit-Queue: Gabriel Charette <gab@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#940917}
>
> TBR=sky@chromium.org,gab@chromium.org,boliu@chromium.org,rdevlin.cronin@chromium.org,sergeyu@chromium.org,skyostil@chromium.org,altimin@chromium.org,seantopping@chromium.org,chromium-scoped@luci-project-accounts.iam.gserviceaccount.com
>
> Change-Id: I5ebcb181286d31e3a0bfb293c394da00e7970da4
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: 1175074, 1253634, 1269720
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3276956
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Reviewed-by: Gabriel Charette <gab@chromium.org>
> Reviewed-by: anthonyvd <anthonyvd@chromium.org>
> Auto-Submit: Gabriel Charette <gab@chromium.org>
> Owners-Override: anthonyvd <anthonyvd@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#941225}
# Not skipping CQ checks because this is a reland.
Bug: 1175074, 1253634, 1269720
Change-Id: Ib0a6a93300425b62458206e2650735850fd68aec
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3279623
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: anthonyvd <anthonyvd@chromium.org>
Reviewed-by: Sean Topping <seantopping@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Gabriel Charette <gab@chromium.org>
Commit-Queue: anthonyvd <anthonyvd@chromium.org>
Commit-Queue: Sean Topping <seantopping@chromium.org>
Owners-Override: anthonyvd <anthonyvd@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941336}
This CL introduces a "process count overhead" metric, based on an
estimate of how many additional processes are needed for
OriginAgentCluster (OAC). It's an estimate since we can't control for
all variables, like the coalescing of SiteInstances from multiple
BrowsingInstances in a single RenderProcess, or the effects of all
possible configurations of the SiteInfo parameters.
The estimate is based on counting the total number of HTTPS
SiteInstances (OAC is only used for HTTPS) by seeing how many unique
SiteInfos they generate in each BrowsingInstance, then converting each
SiteInfo to its non-OAC equivalent and counting again, and comparing
the two counts. The difference is the overhead estimate. This value
should only be reported for users with cross-process OAC enabled.
Basically, this is a best effort approach because knowing the exact
process count requires too much knowledge of process creation history.
It ignores process sharing, which is usually (but not always) an upper
bound on the actual overhead.
Bug: 1171269
Change-Id: I31781bc8dedcb7c4849776d82aacb2890f255142
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3182871
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Caitlin Fischer <caitlinfischer@google.com>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: W. James MacLean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941335}
browser
This CL implements the external interface for the aggregation service
which is created per StoragePartitionImpl instance.
The internal interface for storage (AggregationServiceStorageContext) is
separated from the external interface (AggregationService) to keep a
clean division between internal and external functionalities.
This CL also introduces a feature flag for aggregation service.
from the fact that aggregation_service/ was not being compiled outside
of tests prior. There is dependency on new library which is only 9KB.
Binary-Size: Size increase is unavoidable. Most of binary size comes
Bug: 1264073
Change-Id: Ia68cd6e06d47608c0841c0cfbf998145c4488a63
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3248082
Commit-Queue: Nan Lin <linnan@chromium.org>
Reviewed-by: John Delaney <johnidel@chromium.org>
Reviewed-by: Victor Costan <pwnall@chromium.org>
Reviewed-by: Alex Turner <alexmt@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941329}
From https://html.spec.whatwg.org/multipage/interaction.html#inert,
> A Document document is blocked by a modal dialog subject if subject is
> the topmost dialog element in document's top layer. While document is
> so blocked, every node that is connected to document, with the
> exception of the subject element and its shadow-including descendants,
> must be marked inert.
This doesn't exclude the root element, so it should also be inert.
Simply doing this change would break these tests:
- html/dialog/modal-dialog-ancestor-is-inert.html
- html/dialog/modal-dialog-blocks-mouse-events.html
Excluding the root element in HitTestResult::SetInnerNode avoids that.
Note I plan to track inertness in ComputedStyle, and then remove both
Node::IsInert and hit test retargeting for inert. So this patch is just
temporary, to align with the final behavior.
Also note that only the the root element (documentElement) is affected.
The root node (document), represented as rootWebArea in a11y, will still
not become inert when there is a modal dialog or fullscreen element.
Bug: 692360
TEST=All/DumpAccessibilityTreeTest.AccessibilityModalDialogOpened/blink
TEST=All/DumpAccessibilityTreeTest.AccessibilityModalDialogStack/blink
TEST=All/DumpAccessibilityTreeTest.AccessibilityOpenModal/blink
TEST=external/wpt/html/semantics/interactive-elements/the-dialog-element/inert-node-is-unfocusable.html
Change-Id: I8ce7905a85e386fae6163423f5e078b6c4588db1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3263132
Commit-Queue: Oriol Brufau <obrufau@igalia.com>
Reviewed-by: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941302}
Note that this implementation is fairly minimal, and only dumps a
handful of commonly used fields. We may opt to expand later.
AX-Relnotes: n/a
Bug: fuchsia:87502
Test: n/a
Change-Id: I7dd6cc38d637d50523d3dd83b32976201b1dcacb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3258583
Commit-Queue: Alexander Brusher <abrusher@google.com>
Reviewed-by: David Tseng <dtseng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941294}
Fenced frames use a top-level browsing context in a new browsing context
group, and we would like to limit the number of places where fenced
frames are made to act like a nested browsing context. Therefore,
fenced frames should have "top-level" frame type.
Bug: 1251389
Change-Id: If11573ad393516b6b5c5c2f3e3814430a175bbad
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3275904
Reviewed-by: Ben Kelly <wanderview@chromium.org>
Commit-Queue: Nan Lin <linnan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941288}
The flags have been renamed to make it clear that they only
apply to Windows (see associated bug).
If you're reviewing this CL, please verify your code's usage
of the flag to ensure that the behavior is as intended. Thanks!
This CL was uploaded by git cl split.
R=boliu@chromium.org
Bug: 1244149
Change-Id: Ic583a5bc2a9668d110f6a96d83ee9c45922317ee
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3279146
Auto-Submit: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Commit-Queue: Bo <boliu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941255}
This change updates WebSQL OpenFile to return an invalid file
if GetOrCreateBucket fails. This is necessary because we do not
want to store any data for a StorageKey unless there is a
StorageBucket associated with it. Eventually when WebSQL integrates
with buckets, the data directory for default buckets will change
to a path with a bucket_id. It will not be able to store data
without a bucket. We enforce rule now, before we bootstrap
QuotaDatabase to create buckets for all existing data for
storage keys, and QuotaDatabase becomes the source of truth for
all stored data for quota managed Storage APIs.
Bug: 1267042
Change-Id: Ibac62187e8d82eb6bc2bd6ae794f5da21af5629f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3274860
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Commit-Queue: Ayu Ishii <ayui@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941248}
This reverts commit 67bcc9c2d1.
Reason for revert: suspect for crbug.com/1269720 though I can't
explain why it would cause that failure (and that one alone)
Original change's description:
> [content] Standardize "message loop starts" signal across Desktop, Android, and browser tests
>
> And make content (BrowserMainLoop) responsible for running the
> integration test hook (`MainFunctionParams::ui_task`) instead of each
> BrowserMainParts impl doing so slightly differently.
>
> This is mostly a no-op but for some BrowserMainParts which did more work
> after running `ui_task`, that work will now happen before `ui_task`
> runs.
>
> Metrics recording in //chrome is centralized at the end of
> PreMainMessageLoopRun on all platforms.
>
> Standardizing cross-platform ordering avoids forcing 4 awkward ordering
> requirements in
> https://chromium-review.googlesource.com/c/chromium/src/+/2892251 (see
> diff of TODOs no longer needed after rebasing on this CL :
> https://chromium-review.googlesource.com/c/chromium/src/+/2892251/44..47)
>
> This also allows getting rid of a force function in
> startup_metrics_browsertest.cc to pretend some metrics were logged
> (they now actually are without interfering with the product code).
>
> Part of the uncovered portion of BrowserMainLoop::PreMainMessageLoopRun
> in browser tests was the part setting disallowance to do Blocking/Wait
> operations on main thread. Unfortunately adding this ban breaks many
> tests, browser_test_base.cc explicitly inverts those new thread
> restrictions in this CL with a TODO to bring them in-line with the
> product restrictions.
>
> BrowserMainParts overrides can get also rid of their |run_message_loop_|
> variable when moving handling of the browser test hook (`ui_task`) in
> WillRunMainMessageLoop(). And in a follow-up they will be updated to
> only receive a `bool is_integration_test` from CreateBrowserMainParts
> instead of the full MainFunctionParams which none use beyond that bool.
>
> ContentBrowserTestSanityTests verify that browser test bodies still run
> as expected with this change.
>
> Bug: 1175074, 1253634
> Change-Id: Ib757a02bbd982ef2b1132e2791e8ec1ce0305038
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3187153
> Reviewed-by: Alexander Timin <altimin@chromium.org>
> Reviewed-by: Sean Topping <seantopping@chromium.org>
> Reviewed-by: Scott Violet <sky@chromium.org>
> Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
> Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
> Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
> Reviewed-by: Bo <boliu@chromium.org>
> Commit-Queue: Gabriel Charette <gab@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#940917}
TBR=sky@chromium.org,gab@chromium.org,boliu@chromium.org,rdevlin.cronin@chromium.org,sergeyu@chromium.org,skyostil@chromium.org,altimin@chromium.org,seantopping@chromium.org,chromium-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I5ebcb181286d31e3a0bfb293c394da00e7970da4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 1175074, 1253634, 1269720
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3276956
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: anthonyvd <anthonyvd@chromium.org>
Auto-Submit: Gabriel Charette <gab@chromium.org>
Owners-Override: anthonyvd <anthonyvd@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941225}
The DownloadExtensionTest DownloadExtensionTest_Download_FileSystemURL
was failing when the correct third-party StorageKey was accessed
in the content/browser/download/ files below. This was a result
of the test requesting a navigation to a url in a new tab for the
purpose of downloading, but failing to wait for the navigation to
complete. This produced a race condition involving the StorageKey
value. Waiting for the navigation to complete now produces the
desired result, and DownloadExtensionTest_Download_Open is modified
to remove its waiting logic, now that waiting occurs for all of the
tests that call SetupExtensionFunction.
This one follow-up CL to the FileSystemURLLoaderFactory CL:
https://chromium-review.googlesource.com/c/chromium/src/+/3227339
Bug: 1267272
Change-Id: I39701fd3551a90f703e22d82c0878eaa0756d35e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3276236
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Min Qin <qinmin@chromium.org>
Commit-Queue: Kyra Seevers <kyraseevers@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941193}
In https://crrev.com/c/3247156 we added
functionality in AXNode to compute the "inner text" of a node properly, i.e. taking into
account any formatting that should be added by layout. For example, a block element should start a new line.
"Inner text" is an HTML concept which embodies the above behavior.
In this patch we rename all uses of GetInnerText to GetTextContent in order to make clear
that in most of the accessibility code we do not need the above behavior, but we only
want the text contents without taking layout formatting into account.
In addition, we clarify the methods that return the text content with layout formatting
by adding the "WithParagraphBreaks" suffix.
This patch propagates the UTF16 and UTF8 suffixes to all the code that
retrieves the text content of nodes, in order to enable us to avoid any double caching of both values in
an upcoming patch. This also clarifies to any future developer
the encoding of the text they are retrieving, reducing possible errors.
R=aleventhal@chromium.org
AXRelnotes: n/a.
Change-Id: I8379da9f3e9d55d4c0d84bd36a977bfb605689e5
Bug: 1165853
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3247790
Commit-Queue: Nektarios Paisios <nektar@chromium.org>
Reviewed-by: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Daniel Libby <dlibby@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#941150}
Sandbox::kNoSandboxAndElevatedPrivileges had its own command line
switch, now it is integrated with how utilities are launched. We only
used this sandbox type from utilities so this should work out ok.
Additionally we remove two places where the command line switch
is sniffed from outside //sandbox and force use of helpers instead.
Test expectations in sandbox_integration_tests are adjusted to account
for this.
Bug: 1269423
Change-Id: I410f814e03bc60a2a424a9bcb55bc55aed39005e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3276784
Reviewed-by: Will Harris <wfh@chromium.org>
Reviewed-by: Filip Gorski <fgorski@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941072}
This CL is a part of performance metrics for Prerender on Omnibox with
Direct URL Input:
1. Add a new field to PrerenderTriggerType <-- this CL
2. After crrev.com/c/3260678 is merged, pass kEmbedder and
"_DirectURLInput" to PrerenderHostRegistry in
AutocompleteActionPredictor::StartPrerendering().
Currently, "Navigation.TimeToActivatePrerender" metrics include all
data regardless of the trigger of prerendering. This CL adds a new
field to PrerenderTriggerType to divide metrics depending on the trigger
type.
This CL also adds a unittest PrerenderHostRegistryTest to make sure
the metrics is recorded.
Bug: 1267754
Change-Id: I73a2a1bd2e7ebd6865bd24fea0188b2051866d08
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3261575
Commit-Queue: Asami Doi <asamidoi@chromium.org>
Reviewed-by: Lingqi Chi <lingqi@chromium.org>
Reviewed-by: Huanpo Lin <robertlin@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941070}
This is a reland of 7335d22227
Changes from original CL:
None, but trace_test timeout issues should be fixed by
crrev.com/c/3273676.
Original change's description:
> Switch GPU tests to Python 3
>
> Switches GPU tools and Telemetry-based tests to run exclusively under
> Python 3. This applies both locally (via shebang changes) and on the
> bots (via gn_isolate_map.pyl changes).
>
> Also drive-by fixes a couple of minor issues found while ensuring that
> everything still works as expected.
>
> As a side effect, this should fix the issues we're seeing on ARM-based
> Mac devices with Quartz import errors.
>
> Bug: 1198237, 1266604
> Change-Id: Id2e2bdc8bb3f0ce2877a2fc2398909e3d1e5684a
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3245274
> Auto-Submit: Brian Sheedy <bsheedy@chromium.org>
> Commit-Queue: Brian Sheedy <bsheedy@chromium.org>
> Commit-Queue: Dirk Pranke <dpranke@google.com>
> Reviewed-by: Dirk Pranke <dpranke@google.com>
> Reviewed-by: Kenneth Russell <kbr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#938540}
Bug: 1198237, 1266604, 1267210
Change-Id: I018a01ebca66621cf7e904b09ca062216bf45143
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3265234
Reviewed-by: Dirk Pranke <dpranke@google.com>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Brian Sheedy <bsheedy@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941022}
Without this change, deactivated sources simply disappear from the UI
with no explanation, which makes it harder to debug the API.
Screenshot of changes available in crbug.com/1243319#c12.
Bug: 1243319
Change-Id: Ic6c848ddd011574f77257725612877d4d20c58ea
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3273553
Commit-Queue: Andrew Paseltiner <apaseltiner@chromium.org>
Reviewed-by: John Delaney <johnidel@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941002}
Currently, the purpose of this bit is to indicate to embedders whether
or not a navigation should show loading UI indicators. Currently, same
document navigations never show loading UI because they're always
processed synchronously, so there's no point in flipping to showing
loading UI only to immediately turn it off again. However, in a future
patch, we will introduce a new asynchronous kind of same-document
navigation (as part of the new appHistory API). In preparation for
that, rename to_different_document to should_show_loading_ui to better
indicate what the bit means and how it should be used.
Bug: 1241202
Change-Id: I8c890da3571b80b361644fdf8fbb366336a09f1a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3268574
Reviewed-by: Toni Barzic <tbarzic@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Chris Hamilton <chrisha@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Reviewed-by: Tommy Nyquist <nyquist@chromium.org>
Owners-Override: Charlie Reis <creis@chromium.org>
Commit-Queue: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/heads/main@{#940997}
Instead of storing data relevant only to the internals UI in memory
regardless of whether the internals UI is being used, the manager
instead notifies observers when reports are sent or dropped. The
internals handler registers as such an observer and in turn notifies the
internals UI JS via Mojo.
Note that this is a behavior change, as events will now only be recorded
while an internals page is open.
This should reduce memory usage for browsing sessions that never open
the internals UI, as well as make it easier to add new session-only
data. For example, I will modify crrev.com/c/3206190 to use this
infrastructure.
Bug: 1243319
Change-Id: I58a5de3de46855b0396897d866de3499c8795d16
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3271443
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: John Delaney <johnidel@chromium.org>
Commit-Queue: Andrew Paseltiner <apaseltiner@chromium.org>
Cr-Commit-Position: refs/heads/main@{#940957}
LegacyRenderWidgetHostHWND is shown together with RenderWidgetHostViewAura
window and because it has default style it causing black flash for the
first paint. Set WS_EX_LAYERED window style in order to
LegacyRenderWidgetHostHWND window be blend with windows under it.
Set also WS_EX_NOREDIRECTIONBITMAP flag to avoid additional bitmap in
layered window.
Bug: 1257540
Change-Id: Ia9807e694ccb686e0610980bae2febc9f596e8aa
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3212029
Reviewed-by: Rafael Cintron <rafael.cintron@microsoft.com>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Rafael Cintron <rafael.cintron@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#940943}
It turns out evicting the current frame and/or hiding the Compositor
without doing anything extra results in preventing some resources
from being released/freed. In order to enable freeing of the resources
a minimal compositor frame needs to be submitted.
This patch removes the existing three variations and adds two
new ones:
release: this removes the root cc::Layer and adds a solid color layer,
waits for the frame to be generated, adds back the real root
layer, and hides the compositor.
throttle: when the window is occluded the frame rate is throttled.
This variation won't release resources, but it should
limit the amount of work done in occluded windows.
BUG=1248235
TEST=covered by tests
Change-Id: Ic94314af7b85d3a0797ee9ebc6ccbdedd1df66e4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3273706
Reviewed-by: David Bienvenu <davidbienvenu@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/main@{#940926}
